Unfortunately, as we're now close to 9 months out from my original troubleshooting, I can't recall the exact circumstance, but I can tell you what I recall. We were working with TerraPage databases, referring to external FLT model files for buildings. When one of those building files would page in, the near/far computation would go insane. I traced it down to nodes being copied by the databasepager, I think some shared state related code, using the above copy constructor. The bounding box on the copy was never set from the original, and due to the rest of the database thinking everything was already bounds-computed (I think since the rest of the graph above it had been all computed using the original copy-source node) it was never recomputed and the cull visitor went nuts.
I wish I could give you and exact line by line walkthrough, but I don't think I have that data anymore. I do certify that it was trying to use a non-computed _bbox as a result of the copy constructor. ;) On Fri, Feb 22, 2013 at 2:34 AM, Robert Osfield <[email protected]>wrote: > Hi Chris, > > On 22 February 2013 01:05, Chris Hanson <[email protected]> wrote: > > Robert, a client of mine asked me about this submission recently and > > mentioned he had not seen into trunk yet. Is there any reason that this > > submission would be rejected? > > The submission hadn't been rejected, must have just part of my backlog > I'm afraid. > > I've just done a quick review and while the change looks benign I > don't yet understand why it's required. Normally when application > does a getBound() it will call computeBound() when the bounding volume > is dirty, and the computeBound() should be setting the _bbox. The > LightPointNode is written with this assumption. From your original > post I couldn't work out in which usage model this approach is > insufficient. I'd like to get to the bottom of this as there might be > a wider problem with LightPointNode that the suggested change works > around, but the best fix would be to address the wider problem. > > Robert. > -- Chris 'Xenon' Hanson, omo sanza lettere. [email protected] http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775) 623-PIXL [7495]
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
