Re: [osg-users] Compute near far and multiple cameras
I finally got around to looking at this problem again, so I wanted to post some more details on my solution as guided by Fred and Farshid's conversation in the thread linked above. Farshid's cull callback attached to the pre-render camera is the correct solution, the key being that the traversal operation has to happen before the near/far values are read out. I think I missed that (obvious) fact the first time I tried to solve it this way. There are a few more gotchyas to consider: 1) The cull visitor does some extra clamping of the near plane after the camera traversal returns. This logic is important if you plan to have the camera inside your geometry's bounds, like if you're using a first person manipulator to walk around your model. In that case the computed near plane can be a large negative number since one of the bounding-box borders is behind the camera. The logic you need to add is extracted from CullVisitor::popProjectionMatrix(). It consists of a call to computeNearFarPlane() (which Farshid has in his example), plus a call to clampProjecitonMatrix(...) which clamps the near plane to a proper positive value. You can call getProjectionMatrix() on the CullVisitor to get the current projection matrix that you need to pass into the clamp function. Note that getProjectionMatrix() returns a ref, so you probably want to make a copy of the matrix since the clamp function modifies it and you don't want that to happen twice (once when you call it on the ref, and again when the CullVisitor calls popProjectionMatrix). After this call the projection matrix and near/far values will be identical to the projection matrix that will be used to render the pre-render camera. 2) Be sure to set the pre-render camera near/far mode to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES (or _PRIMITIVES if you choose), but whatever camera you push the planes to should be set to DO_NOT_COMPUTE_NEAR_FAR. Otherwise it will overwrite your settings on its cull pass. With this, I was able to get my near/far clipping working correctly. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56609#56609 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute near far and multiple cameras
Hey Sebastian, I've been looking at this off-and-on for a while now, though I have no clean solution. From my investigation it looks like the osg::CullVisitor tweaks the _computed_znear and _computed_zfar values to their needed settings during the handlle_cull_callbacks_and_traversal() call in the apply(osg::Camera) method. Once the traversal call is complete, the znear and zfar values are correct for all the geometry under that camera. The problem is that between that point and the code a few lines down where the z-values are reset for the next camera there is no mechanism to install a callback to retrieve the computed values. The two solutions I was going to try were: 1) Attach a custom node to the scenegraph in a way that assures it is the last node traversed, is always visited, yet doesn't influence the scene bounds, and then cache off the znear and zfar values from the CullVisitor using a cull callback on that node (seems tricky to manage) Or: 2) Subclass the osg::CullVisitor (which we've already done anyway in our project), copy/paste the virtual apply(osg::Camera) method body, and insert the code that I needed to cache / broadcast the z-values after the traversal. In either case the callback or broadcast mechanism could update the projections for any other cameras down the pipeline before they're hit by the CullVisitor. What I really want is the ability to give one camera references to other cameras as sort of projection slaves and have the osg::CullVisitor set the slave projections after the traversal. I haven't dug through the osg code enough to see if that paradigm is valid or if there's a more obvious solution I'm overlooking. Note that this is all in theory. I haven't been tasked to fix this issue yet in our code, we've just been using hard-coded fixed near/far values in the interim. - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50742#50742 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Licensing of OSG's built-in application executables
Hi all, Does the OSG license allow for distributing the osgviewer.exe and osgconv.exe (or other) executables that are included with the SDK? We want to include those apps in our release so that we can debug cached .ive and .osg files on our customer's machines. I'm just not sure if we would need to write our own simple viewer app so it's a proper derived binary, or if it's okay to just distribute the pre-built ones. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36848#36848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphical issues with display lists on ATI 5870 cards
Hi Wojtek, Thanks for the input, good to know we aren't the only ones seeing issues. We rolled back the drivers to 10.4 and all the issues magically disappeared. I'm disappointed that ATI's QA process doesn't test for such basic feature support with their latest driver releases. We'll have to keep a close eye on this now. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29615#29615 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Graphical issues with display lists on ATI 5870 cards
Hi everyone, My company has been developing products using OSG for a few years now, and recently we've noticed some rendering issues on two machines that are both running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted to know if anyone running similar hardware has seen these issues. We are using the 2.8.2 release of OSG. We notice two major graphical problems: * Incorrect lighting on primitives - flat geometry with equal vertex normals at all vertices appears to have incorrect lighting over the surface (using the default osgviewer lighting) * Corrupted textures - either a single pixel color over the entire surface or it looks like the UV coordinates were run through a blender We have tested rendering using the OSGViewer with a simple .osg file containing two triangles (forming a quad) with identical per-vertex normals and simple per-vertex UVs. What we have found is that we either have to disable display lists on the geometry in order to have the quad render correctly, or else we seem to be able to get correct results by adding additional (bogus) values to the per-vertex normal and UV lists to pad them. We believe this means that somewhere between OSG and the GPU the per-vertex data in the display list is getting corrupted and normals/UVs are getting lost. We have not experienced this issue in any other 3D apps on this hardware, including ones that use display lists. We also do not have the rendering issues with our app on other hardware (tested using several nVidia cards and and older ATI card). We think this may be an ATI driver bug, but we're not sure at this point and would like to hear if anyone else has run into these issues. Thanks. - Andy Peruggi Applied Research Associates, Inc[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29501#29501 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
