Re: [osg-users] VertexBufferObject usage very slow...
Thanks Robert, will do. Happy Holidays! _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Tue, Dec 21, 2010 at 2:53 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sean, On Tue, Dec 21, 2010 at 5:40 AM, Sean Spicer While digging, it looks like there are several ways to optimize vertex arrays for the caches on various GPUs...have you looked at all at this? Are there any reasonable rules-of-thumb for organizing the vertex arrays such that they make efficient use of the vertex cache across a wide swath of commodity hardware? Both NVIDIA and ATI have published advice on the topic. Tim Moore implemented several utility classes for osgUtil that you can use to optimize meshes for caching, see include/osgUtil/MeshOptimizers. The new osganalysis example has some code that illustrates there use. Robert. ___ 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] VertexBufferObject usage very slow...
Robert, Wojciech, Thank you for the advice, this is pretty much exactly what I discovered after some further research. This particular code is pretty old, and I've now re-factored it to use indexed tri-sets instead of tri-strips and things are much better. While digging, it looks like there are several ways to optimize vertex arrays for the caches on various GPUs...have you looked at all at this? Are there any reasonable rules-of-thumb for organizing the vertex arrays such that they make efficient use of the vertex cache across a wide swath of commodity hardware? Both NVIDIA and ATI have published advice on the topic. sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Sun, Dec 19, 2010 at 6:20 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sean, In general when moving from display listed data to VBO's it's best to avoid using tri-strips with separate osg::DrawElements and instead using a single osg::DrawElements containing just GL_TRIANGLES. This will be more duplicated indices but far less overhead in set up and dispatch. With modern graphics hardware and API the biggest overhead is typically the dispatch rather than vertex load on the GPU. Even mid range GPU's can comfortable handle a million+ vertices per frame at 60hz, but... you have to pass the data to them efficiently, and the bottlenecks we were once familiar with have changed. Robert. On Fri, Dec 17, 2010 at 6:57 PM, Sean Spicer sean.spi...@aqumin.com wrote: Robert, Some more data... Looks like we're drawing approx 100K tri-strips every frame. The glDrawElements call is the culprit...though I'm still baffled by why it is so much slower with VBOs than in immediate mode. Perhaps the drawing isn't sorted by VBO so that all of the triangles drawn from each VBO are draw in single bind call ? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote: Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: reproduces the problem you are seeing? ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexBufferObject usage very slow...
Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: reproduces the problem you are seeing? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexBufferObject usage very slow...
Robert, Some more data... Looks like we're drawing approx 100K tri-strips every frame. The glDrawElements call is the culprit...though I'm still baffled by why it is so much slower with VBOs than in immediate mode. Perhaps the drawing isn't sorted by VBO so that all of the triangles drawn from each VBO are draw in single bind call ? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote: Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: reproduces the problem you are seeing? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VertexBufferObject usage very slow...
Hi Everyone, Working off the OSG trunk this afternoon, I tried some experiments with VertexBufferObjects and our geometry (all on the fast path). The only deltas in our code are as follows...all timing as measured by OSG stats: geometry-setUseDisplayList(true) geometry-setUseVertexBufferObjects(false) === Draw time = 2ms, FrameTime = 12ms geometry-setUseDisplayList(false) geometry-setUseVertexBufferObjects(false) === Draw time = 13ms, FrameTime= 19ms geometry-setUseDisplayList(false) geometry-setUseVertexBufferObjects(true) === Draw time = 67ms !!! FrameTime = 109ms What is going on here ? We are always on the fast path - however, our vertex arrays are large (65535 verts). VBOs *should* be way faster than immediate mode...any ideas ? sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSX Install Locations
Hi All, I'm wondering if someone can help me out with an OSX Install Question: (1) Working from the OSG Trunk, I build the OpenSceneGraph using frameworks. I have the CMAKE install directory set to ~/work/OpenSceneGraph-trunk-inst Everything builds cleanly and installs into the specified install directory. (2) I copy the contents of ~/work/OpenSceneGraph-trunk-inst/lib (e.g. all the frameworks + osgPlugins-2.9.9) to /Library/Frameworks (3) I run ~/work/OpenSceneGraph-trunk-inst/share/OpenSceneGraph/bin/osglogo.app Runs fine, but doesn't seem to use the freetype plugin. I looked at the plugins dir, and I find that all the plugins have a .so extension, I presume this doesn't matter. Within the osgPlugins-2.9.9 directory there exists the file: osgdb_freetyperd.so I've also tried putting the plugins in the directory: /Library/ApplicationSupport/OpenSceneGraph/Plugins/osgdb_freetype.so No luck there either. Thoughts? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does OSG function over VNC?
Hi Harry, Have a look at TurboVNC: http://www.virtualgl.org/Downloads/TurboVNC http://www.virtualgl.org/Downloads/TurboVNCsean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Aug 27, 2010 at 2:08 PM, Harry Johnson harry_c_john...@yahoo.comwrote: Hi Robert, Yeah, I understand that the issue is with limited GLX support in the VNC server. However, seeing the glsl_simple.osg actually render, albeit with errors, makes me wonder if there isn't some switch to OSG that would result in it using a 'dumbed down' set of glx features with the understanding that performance/appearance will likely suffer. osgviewer glider.osg does not work. :( It also results in the GLXBadRenderRequest messages. I tried to include the glxinfo output for the VNC server in this post but the forums tell me I have to have 2 posts before I can post a URL... I guess it thinks some of the glxinfo output is actually a URL of some sort. Thank you! Cheers, Harry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31112#31112 ___ 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
[osg-users] BUG REPORT: LineSegmentIntersector
I came across a nasty little bug today: (a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array (b) Try to pick with a LineSegmentIntersector (c) CRASH Digging a little bit, it looks like LineSegmentIntersector assumes that vertex arrays are always of type osg::Vec3Array. Are there any plans to change this ? It looks like a tedious, but not terribly invasive change. sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG REPORT: LineSegmentIntersector
Without giving away too much IP, one of the reasons why one might want to think about using Vec4Arrays is to take advantage of host-side SIMD operations - which commonly use 128bit registers (4 floats). I agree, this is a can of worms. sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Thu, Mar 25, 2010 at 2:53 PM, Jason Daly jd...@ist.ucf.edu wrote: Sean Spicer wrote: I came across a nasty little bug today: (a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array (b) Try to pick with a LineSegmentIntersector (c) CRASH Digging a little bit, it looks like LineSegmentIntersector assumes that vertex arrays are always of type osg::Vec3Array. Are there any plans to change this ? It looks like a tedious, but not terribly invasive change. Interesting find, Sean... My first reaction is, Why would you ever use a Vec4Array for vertex coordinates?!, but an equally valid counter-argument would be that OpenGL allows 4-element vertices them, so OSG should support them. Next, you have to ask how to intersect a line segment with a geometry with Vec4Array vertices. Would you have to do the w-divide on the vertices before you did the intersection tests to be correct, or is it more correct to not do it, or do you have to do the modelview transform, then the w-divide, then the intersection... Then, you have to start wondering if there are any other assumptions like this being made anywhere (I found other possible cases in Tessellator and Optimizer, though it looks as if they just bail out instead of crashing when they don't find a Vec3Array). I think you may have opened a can of worms here :-) --J ___ 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] BUG REPORT: LineSegmentIntersector
Looking at osg::State::setVertexPointer(const Array *array), I see that the stride parameter is always 0. If we relaxed this constraint, and allowed an Array to have a stride, I might be able to overcome the problem I am working on. Any comments on what impact this might have ? Also, in order to accomplish what I'm after, I'd need a mechanism to allocate the underlying array on a 16 byte boundary. It looks as if this should be easily doable as MixinVector is a std::vector. Any thoughts on this? sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Thu, Mar 25, 2010 at 3:05 PM, Sean Spicer sean.spi...@aqumin.com wrote: Without giving away too much IP, one of the reasons why one might want to think about using Vec4Arrays is to take advantage of host-side SIMD operations - which commonly use 128bit registers (4 floats). I agree, this is a can of worms. sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Thu, Mar 25, 2010 at 2:53 PM, Jason Daly jd...@ist.ucf.edu wrote: Sean Spicer wrote: I came across a nasty little bug today: (a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array (b) Try to pick with a LineSegmentIntersector (c) CRASH Digging a little bit, it looks like LineSegmentIntersector assumes that vertex arrays are always of type osg::Vec3Array. Are there any plans to change this ? It looks like a tedious, but not terribly invasive change. Interesting find, Sean... My first reaction is, Why would you ever use a Vec4Array for vertex coordinates?!, but an equally valid counter-argument would be that OpenGL allows 4-element vertices them, so OSG should support them. Next, you have to ask how to intersect a line segment with a geometry with Vec4Array vertices. Would you have to do the w-divide on the vertices before you did the intersection tests to be correct, or is it more correct to not do it, or do you have to do the modelview transform, then the w-divide, then the intersection... Then, you have to start wondering if there are any other assumptions like this being made anywhere (I found other possible cases in Tessellator and Optimizer, though it looks as if they just bail out instead of crashing when they don't find a Vec3Array). I think you may have opened a can of worms here :-) --J ___ 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] Load balancing on multiple cores
One suggestion that I will offer: build your code in release mode, but do not optimize. Under MSVC, use the following flags: /MD /Zi /Od /Ob0 /RTC1 /D NDEBUG You can add the following CMAKE Option to OSGs CMakeLists.txt to add this type of build as an MSVC option in the configuration manager: set(CMAKE_CONFIGURATION_TYPES Debug;RelWithDebInfo;Development;DevelopmentNoOpt CACHE STRING FORCE) set(CMAKE_CXX_FLAGS_DEVELOPMENT /MD /Zi /O2 /Ob1 /D NDEBUG CACHE STRING CMAKE_CXX_FLAGS_DEVELOPMENT FORCE) set(CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENT /debug /INCREMENTAL:YES CACHE STRING CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENT FORCE) set(CMAKE_CXX_FLAGS_DEVELOPMENTNOOPT /MD /Zi /Od /Ob0 /RTC1 /D NDEBUG CACHE STRING CMAKE_CXX_FLAGS_DEVELOPMENTNOOPT FORCE) set(CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENTNOOPT /debug /INCREMENTAL:YES CACHE STRING CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENTNOOPT FORCE) sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Mar 19, 2010 at 1:12 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Jesse, Jesse Stimpson wrote: I feel that we're diverging from what I think is most perplexing about what I'm seeing. When I restrict the process to use less cores, I get increased rendering performance. This is what leads me to believe there are some load-balancing issues. yes, and it would be difficult to see what causes it. Is it OSG, the OpenGL driver or your OS? Unfortunately there is no magic way to get the balance right on all hardware combos. You'll just have to experiment and use what works best in your situation. Also, if I have the OSG process set to both cores and I run another single-threaded process in the background, the other process gets assigned to one core, and OSG rendering speeds up, presumably because it is being processed mainly on a single core. you might find this interesting: http://igoro.com/archive/gallery-of-processor-cache-effects/ I've been playing with the OSG threading models as well. In debug, SingleThreaded mode seems to run the best on my machine. Is there documentation on the implications of the threading models? Not explicitly that I know of. A search in the archives for the long names should get you some discussions. If I understand correctly, SingleThreaded means only the rendering is single threaded, and the database pager is still a separate thread. Is this right? Are reasons we shouldn't consider using SingleThreaded mode? No, use whatever works best for you. We are using SingleThreaded for some of our apps, because they are just a small part of a larger application and we can't use all the resources in the machine for rendering. See also this: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52734 rgds jp Thanks, Jesse ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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] osg::LOD range distance Coordinate System Question
Thanks Robert, This is an odd corner-case I guess, I want the LODs to be selected based upon global distance from the eye-point. For various reasons, onscreen size is inappropriate as a selector. I think I can put together a small example/patch and send it in for review. cheers, sean _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Oct 9, 2009 at 2:06 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sean, You are correct the range distance of LOD's are in the LOD's own local co-coordinate system. This is appropriate as you almost aways want LOD's to scale relative to a screen size, and doing the calc in local coordinate allows you to decorate subgraphs with LOD's with transforms that scale up or down the subgraph and still have the LOD ranges computed appropriate for that new scaling. This behavior is key to get a scene graph to be well encapsulated. It sounds like in your case you have transforms above your LOD's that scale your objects, but you still want their ranges to set in world coords, that ignore any transforms. This would present the problem that is the transforms scale change then the LOD would choose different children - choosing an in-apprioriate level of detail for the on screen size. Robert. On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer sean.spi...@aqumin.com wrote: Studying the source a bit harder, I think the range-distance is definitely in Object (local) coordinate. The distance calculation (osg::LOD.cpp) is: required_range = nv.getDistanceToViewPoint(getCenter(),true); where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp) (pos-getViewPointLocal()).length()*getLODScale(); So, this raises the question: is there a good reason why there is no option to specify the LOD range distance in World Coordinates? This would make complex LOD graphs like the one I'm working on much, much simpler. Perhaps there is another method that I just do not see? cheers, sean On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote: This may be a simple question - is the LOD range distance specified in object or world coordinates? I seems as if it should be in world coordinates, but I've got an example with numerous LOD nodes in sub-graphs, and if I sent a constant distance range in each of them (0.0, 30.0f) so that each LOD node has the same range - the LOD switch only behaves as expected if the transforms above each LOD node are identical. The moment I have a scale matrix above the LOD the switch becomes dependent on the scaling...e.g. larger LODs switch before smaller ones. This leads me to think that the LOD range distance is in object coordinates, and needs to be scaled by the localToWorld transform. I've had a look at the source, and it seems logical (not to mention that I'd be shocked if someone hadn't had a problem before this if it were incorrect) Comments? Thoughts? cheers, sean ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::LOD range distance Coordinate System Question
This may be a simple question - is the LOD range distance specified in object or world coordinates? I seems as if it should be in world coordinates, but I've got an example with numerous LOD nodes in sub-graphs, and if I sent a constant distance range in each of them (0.0, 30.0f) so that each LOD node has the same range - the LOD switch only behaves as expected if the transforms above each LOD node are identical. The moment I have a scale matrix above the LOD the switch becomes dependent on the scaling...e.g. larger LODs switch before smaller ones. This leads me to think that the LOD range distance is in object coordinates, and needs to be scaled by the localToWorld transform. I've had a look at the source, and it seems logical (not to mention that I'd be shocked if someone hadn't had a problem before this if it were incorrect) Comments? Thoughts? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LOD range distance Coordinate System Question
Studying the source a bit harder, I think the range-distance is definitely in Object (local) coordinate. The distance calculation (osg::LOD.cpp) is: required_range = nv.getDistanceToViewPoint(getCenter(),true); where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp) (pos-getViewPointLocal()).length()*getLODScale(); So, this raises the question: is there a good reason why there is no option to specify the LOD range distance in World Coordinates? This would make complex LOD graphs like the one I'm working on much, much simpler. Perhaps there is another method that I just do not see? cheers, sean On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote: This may be a simple question - is the LOD range distance specified in object or world coordinates? I seems as if it should be in world coordinates, but I've got an example with numerous LOD nodes in sub-graphs, and if I sent a constant distance range in each of them (0.0, 30.0f) so that each LOD node has the same range - the LOD switch only behaves as expected if the transforms above each LOD node are identical. The moment I have a scale matrix above the LOD the switch becomes dependent on the scaling...e.g. larger LODs switch before smaller ones. This leads me to think that the LOD range distance is in object coordinates, and needs to be scaled by the localToWorld transform. I've had a look at the source, and it seems logical (not to mention that I'd be shocked if someone hadn't had a problem before this if it were incorrect) Comments? Thoughts? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Perspective Axes Rotation Indicator
Hi Osg-Users, Here's a topic that I cannot seem to find any reference in the archives for. I'm trying to create an Axes rotation indicator Glyph in the lower left-hand corner of our viewer (X, Y, Z). I've got working code for this (see below), but it is an orthographic projection, while my scene is perspective. The axes rotation indicator works correctly, (e.g. it correctly matches the rotation of the trackball scene) but because it is ortho and the scene is perspective, it's quite jarring to the user. Can someone suggest how I can modify the code below so that it correctly maps the axes in perspective (ideally, the same perspective frustum as my scene)? Many thanks. Sean Code --- #ifndef OsgAxes_h #define OsgAxes_h // OSG Includes #include osg/Group #include osg/Geometry #include osg/Camera #include osg/Quat #include osg/MatrixTransform #include osg/Referenced #include osg/NodeCallback #include osgGA/TrackballManipulator class OsgAxes : public osg::Group { public: // Public Constructor explicit OsgAxes(const osgGA::TrackballManipulator trackball); // Public Destructor virtual ~OsgAxes(); void updateCurrentRotation(); private: osg::Geometry *createAxes(); // Prevent Copy Assignment OsgAxes(const OsgAxes ); OsgAxes operator=(const OsgAxes ); osg::ref_ptrosg::MatrixTransform m_rotation; const osgGA::TrackballManipulator m_trackball; }; class AxesNodeCallback : public osg::NodeCallback { public: virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) { osg::ref_ptrOsgAxes axes = dynamic_castOsgAxes* (node); if(axes) { axes-updateCurrentRotation(); } traverse(node, nv); } }; OsgAxes::OsgAxes(const osgGA::TrackballManipulator trackball) : m_trackball(trackball) { osg::Camera *camera = new osg::Camera; //camera-setProjectionMatrix(osg::Matrix::ortho2D(0, 1280, 0, 1024)); camera-setProjectionMatrix(osg::Matrix::ortho2D(0, 1280, 0, 1024)); camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); camera-setViewMatrix(osg::Matrix::identity()); camera-setClearMask(GL_DEPTH_BUFFER_BIT); camera-setRenderOrder(osg::Camera::POST_RENDER); camera-setAllowEventFocus(false); osg::Geode* geode = new osg::Geode(); // turn lighting off for the text and disable depth test to ensure it's always ontop. osg::StateSet* stateset = geode-getOrCreateStateSet(); stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF); geode-addDrawable(createAxes()); m_rotation = new osg::MatrixTransform(); m_rotation-setMatrix(osg::Matrix::identity()); m_rotation-addChild(geode); osg::MatrixTransform *scale = new osg::MatrixTransform(); scale-setMatrix(osg::Matrix::scale(osg::Vec3(100.0f, 100.0f, 100.0f))); scale-addChild(m_rotation.get()); osg::MatrixTransform *translate = new osg::MatrixTransform(); translate-setMatrix(osg::Matrix::translate(osg::Vec3(100.0f, 100.0f, 0.0f))); translate-addChild(scale); camera-addChild(translate); addChild(camera); setUpdateCallback(new AxesNodeCallback); } OsgAxes::~OsgAxes() { } osg::Geometry * OsgAxes::createAxes() { osg::Geometry* geom = new osg::Geometry; osg::Vec3Array* vertices = new osg::Vec3Array; vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f)); vertices-push_back(osg::Vec3(0.5f, 0.0f, 0.0f)); vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f)); vertices-push_back(osg::Vec3(0.0f, 0.5f, 0.0f)); vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f)); vertices-push_back(osg::Vec3(0.0f, 0.0f, 1.0f)); geom-setVertexArray(vertices); osg::Vec3Array* normals = new osg::Vec3Array; normals-push_back(osg::Vec3(0.0f,0.0f,1.0f)); geom-setNormalArray(normals); geom-setNormalBinding(osg::Geometry::BIND_OVERALL); osg::Vec4Array* colors = new osg::Vec4Array; colors-push_back(osg::Vec4(1.0f,0.0,0.0f,1.0f)); colors-push_back(osg::Vec4(0.0f,1.0,0.0f,1.0f)); colors-push_back(osg::Vec4(0.0f,0.0,1.0f,1.0f)); geom-setColorArray(colors); geom-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE); geom-addPrimitiveSet(new osg::DrawArrays(GL_LINES,0,6)); osg::StateSet* stateset = geom-getOrCreateStateSet(); osg::LineWidth *lw = new osg::LineWidth(2.0f); stateset-setAttribute(lw); return geom; } void OsgAxes::updateCurrentRotation() { osg::Matrix mat(m_trackball.getRotation().inverse()); m_rotation-setMatrix(mat); } --- End Code ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Hi J-S, Try this: void QOsgScene::drawBackground ( QPainter * painter, const QRectF rect ) { if (m_redrawEnabled == false){ return; } emit aboutToDraw(); // Only works with OpenGL if( painter-paintEngine()-type() == QPaintEngine::OpenGL ) { GLenum errorNo; // Qt OpenGL State Initialization takes // place before we get here, on every frame. // We can assume that OpenGL state is reset to // default on every frame. // Push initialized state onto the stack so that we can // Recover it later for further Qt Drawing. glPushAttrib(GL_ALL_ATTRIB_BITS); glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS); // Fixup stuff that Qt Modifies from default state that // OSG expects. glShadeModel(GL_SMOOTH); // Push matricies glMatrixMode(GL_TEXTURE); glPushMatrix(); glLoadIdentity(); glMatrixMode(GL_PROJECTION); glPushMatrix(); glLoadIdentity(); glMatrixMode(GL_MODELVIEW); glPushMatrix(); glLoadIdentity(); // Make sure that OSG's state is prepared based on the last state // recorded (if available). The first frame is different. osg::State *state = getCamera()-getGraphicsContext()-getState(); state-reset(); state-apply(m_lastStateSet.get()); // Run a frame: this is where the action happens. frame(); // Store the OSG state for restoration in the next frame. getCamera()-getGraphicsContext()-getState()-captureCurrentState(*m_lastStateSet); // Pop matricies. glMatrixMode(GL_PROJECTION); glPopMatrix(); glMatrixMode(GL_TEXTURE); glPopMatrix(); glMatrixMode(GL_MODELVIEW); glPopMatrix(); // Pop Attribs, now we're ready to continue // Drawing with OpenGL. glPopAttrib(); glPopClientAttrib(); errorNo = glGetError(); if (errorNo!=GL_NO_ERROR) { LOG_MSG(logERROR) Post-Frame: Detected OpenGL error (frame m_frameNo ) ' gluErrorString(errorNo) '; } ++m_frameNo; } else { qWarning(QOsgScene: drawBackground needs a QGLWidget to be set as viewport on the graphics view.); } } _ Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.281.466.4848 Mobile...+1.713.447.2706 Fax...+1.281.466.4849 On Tue, Apr 21, 2009 at 1:28 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hello Christian, I have run into another problem. With my current approach the scene loses all lighting after the first frame has been drawn. All polygons appear in flat shading. I have currently no idea what is causing this. At first I was not noticing this because I rendered cow.osg which uses a metallic effect (environment maps?). But on other scenes the loss of lighting is apparent. This suggests that when pushing and popping state in order for Qt to draw its widgets, something is not pushed/popped correctly, probably GL_LIGHTING, GL_LIGHT0-GL_LIGHT7 or something like that? Perhaps glShadeModel? ... Just a possible avenue for investigation. I know it sounds obvious, but the error is obviously caused by something you overlooked, so listing things that should not be overlooked seems like the only way I can help... :-) J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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] KDTree Picking (at an angle)
Robert, I think I know why things go bad in KDTree, I'm using KDTree to spoof the location of some actual geometry, which is transformed in a vertex/geometry shader. So, I compute a bounding box for where the geometry ought to be, and create a dummy geometry from that - I then compute the KDTree for this dummy geometry, and assign it to the actual geometry that will be sent down the pipe, which is at the scene origin, not its final location. When the line-segment intersector goes to pick, it first checks to see if the line segment intersects the bounding box of the drawable, which as far as I can tell is computed against the actual geometry (in this case the geometry at the origin) and not the KDTree's bounding box. When it doesn't properly intersect, the line-segment intersector returns without hitting the KDTree. I think what is needed is to test against the KDTree bounding box, rather than the geometry bounding box, if a KDTree is assigned. Does this make any sense? sean On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED] wrote: Robert, I will see if I can repro the problem with osgpick and send you the osg file. It may take me a week or two though as I've got a lot on my plate ;-) cheers, sean On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, This sounds like a bug, but without a dataset and example that reproduces the problem it's next to impossible to home in on a fix. Would it be possible for you to provide a problem dataset that illustrates the problem? If it can be reproduced with one of the existing examples like osgpick then this will make it easier to track down. Robert. On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED] wrote: Hi Gang, I'm working on improving picking performance via KDTree, but I'm hitting an issue that is driving me nuts: If I pick a node from directly above (e.g. + Z axis) everything works great, and picking is *very* fast. If I pick at an angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes to the left, right, top, or bottom get picked instead of what I'm after. Here is my KDTree Build function: #ifdef USE_KDTREE // Update the KDTree osg::KdTree::BuildOptions kdTreeBuildOptions; osg::ref_ptrosg::KdTree kdTree = new osg::KdTree(); if(kdTree-build(kdTreeBuildOptions, geometry)) { geometry-setShape(kdTree.get()); } else { LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.; } #endif Any suggestions? cheers, sean ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Will do, and I'll report back... sean On Thu, Dec 4, 2008 at 1:07 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, Yes this makes sense. There is a mechanism in Drawable that allows you to define an inital bound that is used in the compute of the geometry position, this was done quite a few years ago at begining of the journey in the land of vertex shader. These days I think a better solution would be to just allow users to manually define it and disable the automatic compute of the bounding volume. So try using geometry-setInitialBound(bb); Where bb is the max size you expect the goemetry to get to/or the bound that you used for the KdTree. If that works OK I can look at cleaning up the overriding of the computed bound. Robert. On Thu, Dec 4, 2008 at 6:30 PM, Sean Spicer [EMAIL PROTECTED] wrote: Robert, I think I know why things go bad in KDTree, I'm using KDTree to spoof the location of some actual geometry, which is transformed in a vertex/geometry shader. So, I compute a bounding box for where the geometry ought to be, and create a dummy geometry from that - I then compute the KDTree for this dummy geometry, and assign it to the actual geometry that will be sent down the pipe, which is at the scene origin, not its final location. When the line-segment intersector goes to pick, it first checks to see if the line segment intersects the bounding box of the drawable, which as far as I can tell is computed against the actual geometry (in this case the geometry at the origin) and not the KDTree's bounding box. When it doesn't properly intersect, the line-segment intersector returns without hitting the KDTree. I think what is needed is to test against the KDTree bounding box, rather than the geometry bounding box, if a KDTree is assigned. Does this make any sense? sean On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED] wrote: Robert, I will see if I can repro the problem with osgpick and send you the osg file. It may take me a week or two though as I've got a lot on my plate ;-) cheers, sean On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sean, This sounds like a bug, but without a dataset and example that reproduces the problem it's next to impossible to home in on a fix. Would it be possible for you to provide a problem dataset that illustrates the problem? If it can be reproduced with one of the existing examples like osgpick then this will make it easier to track down. Robert. On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED] wrote: Hi Gang, I'm working on improving picking performance via KDTree, but I'm hitting an issue that is driving me nuts: If I pick a node from directly above (e.g. + Z axis) everything works great, and picking is *very* fast. If I pick at an angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes to the left, right, top, or bottom get picked instead of what I'm after. Here is my KDTree Build function: #ifdef USE_KDTREE // Update the KDTree osg::KdTree::BuildOptions kdTreeBuildOptions; osg::ref_ptrosg::KdTree kdTree = new osg::KdTree(); if(kdTree-build(kdTreeBuildOptions, geometry)) { geometry-setShape(kdTree.get()); } else { LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.; } #endif Any suggestions? cheers, sean ___ 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 ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Robert, I will see if I can repro the problem with osgpick and send you the osg file. It may take me a week or two though as I've got a lot on my plate ;-) cheers, sean On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, This sounds like a bug, but without a dataset and example that reproduces the problem it's next to impossible to home in on a fix. Would it be possible for you to provide a problem dataset that illustrates the problem? If it can be reproduced with one of the existing examples like osgpick then this will make it easier to track down. Robert. On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED] wrote: Hi Gang, I'm working on improving picking performance via KDTree, but I'm hitting an issue that is driving me nuts: If I pick a node from directly above (e.g. + Z axis) everything works great, and picking is *very* fast. If I pick at an angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes to the left, right, top, or bottom get picked instead of what I'm after. Here is my KDTree Build function: #ifdef USE_KDTREE // Update the KDTree osg::KdTree::BuildOptions kdTreeBuildOptions; osg::ref_ptrosg::KdTree kdTree = new osg::KdTree(); if(kdTree-build(kdTreeBuildOptions, geometry)) { geometry-setShape(kdTree.get()); } else { LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.; } #endif Any suggestions? cheers, sean ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] KDTree Picking (at an angle)
Hi Gang, I'm working on improving picking performance via KDTree, but I'm hitting an issue that is driving me nuts: If I pick a node from directly above (e.g. + Z axis) everything works great, and picking is *very* fast. If I pick at an angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes to the left, right, top, or bottom get picked instead of what I'm after. Here is my KDTree Build function: #ifdef USE_KDTREE // Update the KDTree osg::KdTree::BuildOptions kdTreeBuildOptions; osg::ref_ptrosg::KdTree kdTree = new osg::KdTree(); if(kdTree-build(kdTreeBuildOptions, geometry)) { geometry-setShape(kdTree.get()); } else { LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.; } #endif Any suggestions? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDB loader question
Is there a way to load files from a byte-buffer? I'd like to be able to store certain shape-files as resources and load them with something similar to: osgDB::readNodeFile(shapeFile) something like: osgDb::readFromByteBuffer(char *buffer, size_t size); I can't find anything like this in the API, does it exist? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull-Traversal Performance
Robert, interesting. Thank you for the detailed explanation. Looking at the osgforest shader-path, one challenge that I see is that if one needs to be able to pick the geometry, then the SG doesn't know about where it is in space to run an interesector. Any thoughts on a strategy to overcome this? I was thinking about hidden geometry, but the intersector wouldn't see it. cheers, sean On Fri, Oct 31, 2008 at 4:31 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, Welcome back :-) Transforms are relatively expensive, as the transforms need to be tracked as well as the view frustum needing to be transformed into the local coords below the transform for culling performance. You two subgraphs have 100 vs 10,000 transforms per frame, 100 won't take the cull traversal much at all, but 10,000 will. Second up having lots of separate osg::Geometry, even when a small number of shared many times, requires lots of work in cull in doing the actual cull test and more critically creating all the RenderLeaf back end data structure required to represent the Geometry instance with its final combination of modelview, projection and state. So as a general rule, keep the number of transforms down, by applying the transforms to the subgraphs and copying the geometry if required, and keep the the number of separate geometries down by combining smaller geometries into bigger groups. Since you culls do look rather high even with the small scene set up, while it's a bit of long shot, make sure that you do all your tests in release/optimized build. Another area you could look at at inspiration is the osgforest example - it provides a range of implementations of forests that you can step between, in the svn/trunk version of the OSG I've added in the StatsHandler to show the relative costs of cull/draw and GPU. You run the osgforest example with a command line option to set the number of trees for instance: osgforest --trees 1 This will give you an indication of the how each of the techniques might work in your instance. In particular the shader path would probably be most applicable. Other items you could look at is the use the multi-threaded use of osgViewer, as the DrawThreadPerContext would certainly help hide the cost of your long cull. Finally we have had some check-in's since OSG-2.6 include optimizations in Matrix that reduce the overhead associated with Transforms. So try out the SVN/trunk or 2.7.x developer releases. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.281.466.4848 Mobile...+1.713.447.2706 Fax...+1.281.466.4849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull-Traversal Performance
Thanks. Is there a primmer on osg::KdTree anywhere? sean On Fri, Oct 31, 2008 at 9:37 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, On Fri, Oct 31, 2008 at 2:16 PM, Sean Spicer [EMAIL PROTECTED] wrote: Looking at the osgforest shader-path, one challenge that I see is that if one needs to be able to pick the geometry, then the SG doesn't know about where it is in space to run an interesector. Any thoughts on a strategy to overcome this? I was thinking about hidden geometry, but the intersector wouldn't see it. The where on earth is it paradox with vertex shaders.. Probably the easiest way to solve would be to manually create an osg::KdTree for where the geometry would be if it had been transformed and then attach this KdTree to the Drawable where the vertex shader is playing games. This would speed intersections as well as solve the where on earth is it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.281.466.4848 Mobile...+1.713.447.2706 Fax...+1.281.466.4849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reversed Normal in Smoothing Visitor on TRIANGLE_STRIP
Hi All, OSG 2.7.4 - I'm seeing a reversed normal when running osgUtil::SmoothingVisitor on a drawable containing only tri-strips. Not sure if it is the first or last vertex, but I've repeated it with several different examples. Has anyone else seen this? sean -- Sean Spicer Executive Vice President Chief Technology Officer Aqumin (www.aqumin.com) Office+1.281.466.4848 Mobile...+1.713.447.2706 Fax...+1.281.466.4849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cull-Traversal Performance
Hi Folks, First off, let me say that it's good to be back on the list - it has been awhile ;-) I'm trying to tune a scene-graph representing a relatively-large model. I'm seeing what I think are abnormally long cull-traversal times. The SG looks as follows: (State is constant across the entire scene) [Group] x 1 | [Switch] x 1 | [MatrixTransform] x 100 | [Geode] x 1 | [Geometry] x 100 There are approx 10K Geometry Drawables in the overall scene. The cull traversal for this scene graph is approx 10ms on a 2.5GHz Core2Duo processor. If I change the SG to the following: [Group] x 1 | [Switch] x 1 | [MatrixTransform] x 100 | [Switch] x 1 | +-+ | | [Geode] x 1 [MatrixTransform] x 100 | | [Geometry] x 100 [Geode] x 1 | [Geometry] x 1 and I turn on the new branch, the cull traversal jumps to 80ms. If I eliminate the single Geometry node below the new geode (so that the new branch is still there, but doesn't draw anything, cull-traversal falls to 40ms. Can anyone help explain what is going on here? These cull-traversal times seem long relative to the complexity of the scene and the speed of the processor - I'm trying to hit a 60Hz frame-rate, and even 10ms for the cull is just not going to cut it. For better or worse, there isn't a good way to simplify the complexity of the scene. cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org