Yes, I've been following this thread silently and wondering how my occlusion query work could be applied to the situation.
I've implemented this as an OcclusionQueryNode, derived from Group, which uses occlusion query to determine whether or not to render its children. I've also implemented a custom RenderBin to sort the scene in front-to-back order to maximize possible occlusion. The OcclusionQueryNode creates a simple bounding geometry representation of its children and performs an occlusion query test on that simple geometry. This could return "false visibles" because it's possible that the simple bounding geometry might be "visible" even though the actual geometry is occluded. This isn't really an issue for my client. However, in the context of this current discussion, this is an issue that would need to be addressed, I'd think. The way to fix it is to perform the occlusion query on the actual geometry, not on the simple bounding geometry. This poses a real challenge in OSG, because the scene graph hierarchy is lost after the cull traversal. You would need to call glBeginQuery(), draw a subgraph, then call glEndQuery(). But during the draw traversal you have no access to the subgraph itself, just its Drawables, which might get moved around due to sorting. I've given some thought to creating a custom RenderLeaf that would preserve Drawables within a subgraph in a contiguous list so that occlusion queries could be performed on that group, but haven't actually implemented this yet. On the other hand, one of the classes I've created in this project is called QueryGeometry. As its name implies, it derives from Geometry, but performs an occlusion query test on its data. OcclusionQueryNode uses this class to store the simple bounding geometry. However, you could store any geometric data in it. So, if the object you want to test fits in a single Drawable, then you could use QueryGeometry instead. This would then test on the actual geometry, and (partially) gets around the "subgraph" issue. If you're interested in looking at my code, the current status is as follows: beta testing turned up some issues, most of which have been worked around with options and environment variables. I've been working on the code recently to make it function better "out of the box". The project is open source and should be available to the public sometime this summer. Intent is to contribute it back to OSG. If you need access before that happens, contact me offline and we can discuss. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Friday, June 22, 2007 7:04 AM > To: osg users > Subject: Re: [osg-users] fast "is-visible" test > > I think you best hope is using OpenGL occlusion query to get > pixel coverage. There isn't going to be an easy solution for > what you want though, it won't be fast and it won't be > straight forward to code. > > Paul Martz has been doing work on occlusion querry so perhaps > his work once open sourced may be a use, or guidance. > > On 6/22/07, Oliver Schoenborn <[EMAIL PROTECTED]> wrote: > > It could be either extreme: any pixel seen, or whole object > has to be > > seen. But just being in view frustum is not enough (could > be wholy or > > partially occluded by other objects). Thanks, Oliver > > > > Robert Osfield wrote: > > > Hi Oliver, > > > > > > How exactly would you define being "look at"? Any part > of the model > > > in the view frustum, any pixel on the objects seem? > > > > > > Robert. > > > > > > On 6/21/07, Oliver Schoenborn > <[EMAIL PROTECTED]> wrote: > > >> I would like to change the color of a geode in one scene > view (call > > >> it > > >> B) based on how "often" a geode is visible in another scene view > > >> (call it A). I.e., the longer the geode is being "looked > at" in A, > > >> the brighter its corresponding geode gets in B, up to > some saturation value. > > >> If I only had a small number of such geodes I could use > > >> IntersectVisitor but I have a large number of them (about 1 > > >> million), so I'm looking for better ways. > > >> > > >> I suppose a fragment shader might work, if two > conditions are met: > > >> > > >> 1. Textures (as 2D arrays) can be written to by one > shader, and read > > >> from by another > > >> 2. A shader only gets called for a fragment if > fragment is visible -- > > >> not occluded by anything else. > > >> > > >> Any easier way? Any comments on above greatly appreciated. > > >> Oliver > > >> > > >> _______________________________________________ > > >> 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/ > > > > > > -- > > Oliver > > skype: schoenborno > > > > _______________________________________________ > > 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/
