Well I want the sun glare to be potentially occluded by everything in our scene. So if a small sign post occludes the sun, I want it to affect it. In a driving simulation the one frame delay will not be noticeable guaranteed. At least when talking about scaling a lens flare.
It sounds to me like you guys think occlusion querying the whole database for the sun would be taxing? Maybe I should go back to querying the depth buffer then? Zach -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Maslowski Sent: Tuesday, December 12, 2006 11:13 To: 'osg users' Subject: RE: [osg-users] Sun occlusion Hi Robert, It worked fairly well for me in both contexts, although my application was pretty special-purpose (FPS). For effects, the objects pixel coverage was simply used as a factor for the intensity of the effect. For culling, it was far more complex. As you said, the results have to be treated far more conservatively. So, anything occupying ~5 pixels would be considered visible. If an object was moving extremely fast, I would always draw it. If the frame rate was very low, I would be more conservative in my pixel coverage. One thing worth mentioning is that I automatically picked occluders when sorting my objects (size, distance to camera, material settings), and rarely ever used an objects full representation when doing occlusion queries. When exporting objects from the art package, the artist could define an internal bounding sphere, box, or hull which could be used for occlusion tests. These simplified objects were used for the queries since they could be rendered in no time, but still gave useable results. It's been about four years since I worked with that code, and quite a few things have changed in respect to working with the GPU, but it proved to be a useful approach at the time. Unfortunately, I never used a traditional, CPU based occlusion system in the same code base, so I don't have numbers to compare. All I remember is that it certainly worked in our favor since the CPU was already overloaded with AI and physics work. This whole approach was grabbed from an article released by NVIDIA for the Game Developers Conference (2001...I think). E. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, December 12, 2006 10:22 To: osg users Subject: Re: [osg-users] Sun occlusion HI Eric, On 12/12/06, Eric Maslowski <[EMAIL PROTECTED]> wrote: > This really isn't noticeable unless you have very fast objects, or > very low > frame rates (sub-20fps). As long as you intelligently choose your occluders > and conduct some simple tests to identify the above, there shouldn't > be any > problems. In what context, culling or special effects? Culling has to be conservative otherwise objects get culled that shouldn't be. If you are having to be overly conservative then you are also not getting the most of the potential culling. One has to be very careful about making sure the benefits you gain outweigh the costs involved, if you are loosing efficiency of culling then the cost benefits shift against you. Personally I'm pretty skeptical about using occlusion querry for culling in anything other than quite specific apps. For special effects things are much less critical. For special effects like lens flare one has to use almost the whole scene as occluders, with lens affect as post process. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
