Shadow volumes sooo slow...

Using beam trees and static geometry/lights will certainly boost performance but I guess implementing that will be much work since my complete engine is designed for dynamic use at the moment. But probably there is no way round static components with the current hardware…

But before completely giving up my dynamic concept I still want to try the scissor optimization and the other optimization proposed by cass.

I don’t know if I’m understanding the scissor test correctly:
You need to project the light sphere into screenspace. For doing that you could use gluProject to get the middle point (x, y) of the sphere and the radius (rad) in screenspace. After that you set the scissor function with the following parameters: glScissor(x - rad, y - rad, 2 * rad, 2 * rad). Ist that correct or is there a better way? Please tell me if I’m missing something here…

Thanks in advance
LaBasX2

P.S.: @Cass: A paper about shadow volume optimization would be really a great and helpful thing. The last paper about infinite shadow volumes was excellent in my opinion!

[This message has been edited by LaBasX2 (edited 07-12-2002).]

I agree, a follow up paper would rock!

BTW, any one have some source that shows building and using a beam tree? I have looked around all over the place but no luck.

-SirKnight

yeah, a follow up would be too cool. as this is one of the best papers i’ve ever read. read it, implemented it. took me about an hour from zero to volumetric shadows…

Beam Trees & Shadow Volume Bsp’s: http://www.cs.wpi.edu/~matt/courses/cs563/talks/bsp/document.html
(at the bottom of the document) http://www.flipcode.com/harmless/issue01.htm#beamtrees
These are the most usefull links I found.
You can always check out my tenebrae sources. It implements a SVBsp (& scissoring & precalculation) but I don’t know if it works (Essentially the vis of quake works so well polygons are cut most of the time before they can be checked against the svbsp)
(Note that I will release a new (cleaner) version “soon”.)

Charles

[This message has been edited by Pentagram (edited 07-13-2002).]

Ok, I’ve seen that calculating the scissor box seems to be a bit more complicated than I thought…

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00005303&forum=3dtheory&id=-1

I have sample code for scissor rectangle determination up at that link. Probably has some bugs, but the theory is sound ( and it works .)

[This message has been edited by Catz (edited 07-16-2002).]

[This message has been edited by Catz (edited 07-16-2002).]

Great! Thanks for the link!

Just noticed this,
http://oss.sgi.com/projects/ogl-sample/registry/EXT/stencil_two_side.txt

I don’t think it will reduce fill rate consumption but it should still improve performance.

EDIT: Ok, it won’t help you now, since no hardware supports it except the new Radeon 9700 ( as far as I know ).

[This message has been edited by PH (edited 07-20-2002).]

one question about the twosidedstencil. what if i disable it, and let stenciltest enabled. is then the frontface or backface settings the one, that will be set in the singlesidedstencil? or are those values indepenend of the singesidedstenciltest? its not explicit defined in the ext, and i’m not sure about it… is it a bit like multitexturing, or is it simply a replacement and does not map onto the standart stencil settings?

With two-sided testing disabled, the front state is used ( like two-sided lighting I believe ).

Originally posted by PH:
Ok, it won’t help you now, since no hardware supports it except the new Radeon 9700 ( as far as I know ).

The spec comes from NVidia, so I think they will soon support the extension (plus, it’s a EXT_ one). The fact that ATI already supports it is really good! I’ll modify my codepaths to make use of it.

Julien.

I meant to say that the Radeon 9700 hardware supports two-sided stencil testing not the extension ( but it most likely will ). I noticed an ATI specific extension in glATI.h that hinted that the Radeon 9700 supported this functionality but it has been removed again ( this was prior to it’s launch, so it’ll probably be added again - the extension was/is called GL_ATI_separate_stencil ). Other things worth mentioning is that the Radeon 8500 apparently supports NV_point_sprite and NV_occlusion_query ( these are still in the header file ). It’s nice to see these extensions implemented in other vendors drivers.

Originally posted by PH:
Other things worth mentioning is that the Radeon 8500 apparently supports NV_point_sprite and NV_occlusion_query ( these are still in the header file ). It’s nice to see these extensions implemented in other vendors drivers.

Could someone confirm NV_occlusion_query is really supported by ATI, please? If that’s true, then it’s real good news for me since the engine I’m working on needs occlusion queries (I was hoping it would be mainstream in 2 years and didn’t expect it was coming so earlier )

Julien.

I can’t say with 100% certainty since these extensions are not in my drivers but have a look at this,
http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/Extensions/glATI.h

Two weeks ago there were a few more extensions and a “Radeon 9xxx” line so I would expect a site update soon. Oh, and the ATI_map_object_buffer extension complements VAO nicely.

And notice the it contains a GL_EXT_texture_rectangle which is supported on Radeon 7xxx / 8xxx. I don’t have the spec but it’s probably like the NV version.

Sorry for the offtopic posts .

Originally posted by deepmind:
Could someone confirm NV_occlusion_query is really supported by ATI, please?

That’s a definite yes . I’ve just used it ( and NV_point_sprite ) with the 6118 Radeon 8500 drivers. The extensions are not in the extension string, so they are probably not free of bugs ( the point sprite extension has a few bugs I think ).

EDIT: ARB_vertex_program is also in this driver set but I don’t think it’s complete yet.

[This message has been edited by PH (edited 07-23-2002).]