Re: [osg-users] Multipass Rendering objects that intersect given shapes/bounding volumes
David, Now that I've had a chance to review the literature, this does seem like a much better approach. Of course, convincing everyone to throw away all the work we've done in the mean-time will be an interesting exercise in diplomacy, but it will be worth it. Thanks for the pointer. -Chris B On Mon, Dec 8, 2008 at 10:01 AM, David Spilling <[EMAIL PROTECTED]> wrote: >> am I understanding correctly that >> what's primarily done is to use the Z-buffer to cut down on the amount >> of geometry that has to be lit? > > From what I understant, that's not quite it. You render the scene with no > lighting, but enough info per pixel to sort out the lighting later (in one > lighting pass). It requires multirender targets, as you need things like the > normal, and (sometimes) the pixel depth, and material properties/material > index. It's a technique that is fairly orthogonal to the normal rendering > approach, but from what I've read seems particularly good for large numbers > of lights. > > However rather than me trying to explain it (badly) I'll defer to the > various papers on it that you can find. There are also some good demos > around. > > David > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass Rendering objects that intersect given shapes/bounding volumes
> > am I understanding correctly that > what's primarily done is to use the Z-buffer to cut down on the amount > of geometry that has to be lit? > >From what I understant, that's not quite it. You render the scene with no lighting, but enough info per pixel to sort out the lighting later (in one lighting pass). It requires multirender targets, as you need things like the normal, and (sometimes) the pixel depth, and material properties/material index. It's a technique that is fairly orthogonal to the normal rendering approach, but from what I've read seems particularly good for large numbers of lights. However rather than me trying to explain it (badly) I'll defer to the various papers on it that you can find. There are also some good demos around. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass Rendering objects that intersect given shapes/bounding volumes
David, Interesting. I'll read some of the papers on this later this week when I have some more time. Based on my cursory glance at the wikipedia entry on 'deferred rendering,' am I understanding correctly that what's primarily done is to use the Z-buffer to cut down on the amount of geometry that has to be lit? If so, I think that's pretty close to the technique we're using currently. The scene is rendered with a global light (the sun or moon), and then the individual lights are additively blended into the scene with the depth test set to LEQUAL, so any geometry discarded by the depth test won't be shaded. Am I missing some other obvious benefit of deferred rendering? I do tend to be a bit oblivious at times (especially this early in the morning...) -Chris B On Sat, Dec 6, 2008 at 8:02 AM, David Spilling <[EMAIL PROTECTED]> wrote: > Chris, > > Not that it really answers your direct question, but have you tried looking > at a deferred rendering approach? With that many lights I would have thought > the performance benefits would be good. > > David > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass Rendering objects that intersect given shapes/bounding volumes
Chris, Not that it really answers your direct question, but have you tried looking at a deferred rendering approach? With that many lights I would have thought the performance benefits would be good. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multipass Rendering objects that intersect given shapes/bounding volumes
Hi all, I'm currently working on extensions to our existing application to allow us to render several (as in 100+) lights in a single scene and (hopefully) maintain usable framerates. Currently I'm using a cull callback to create multiple RenderStages so that the lights can be additively blended into the image after the initial rendering pass with a global light (like in the osgmanylights example). Since the lights are all spot lights, the first optimization I used was to render a cone into the stencil buffer so that only the pixels that could possibly be affected by the light were re-rendered. This actually (I think) exposed a bug in CullVisitor's handling of StateSets, but that'll be the subject of another e-mail once I've gotten a simpler example coded up to show what happens... The next step I want to take is to use this cone geometry (or even the cone's bounding box/sphere) as a pre-processing step to eliminate portions of the scene graph that won't be affected by the light as well (since the Stencil buffer test means that the geometry gets all the way to the raster stage before it's discarded). I'd like some advice as how to tackle this in a fashion that fits in with the 'OSG' way to do things. :) My initial thoughts were to do something like inherit IntersectionVisitor, but then should this new Visitor return a new subgraph of the nodes that will be affected by the lighting pass? Or should it do something like change the nodemasks of the nodes so that, by modifying the CullVisitor's traversal mask, only the nodes that could be lit in the lighting pass will be visited? Or should I just screw with the frustum/polytope of the CullVisitor somehow to make it a reasonable approximation of the cone's bounding box? I didn't see any option to be able to specify a bounding volume for a CullVisitor, but I'd be happy to know that I'd overlooked something like that... So can someone set me straight? Am I heading in completely the wrong direction here? Thanks! -Chris B ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
