Hi Chris, Thanks for the explanation. Copying a LightPointNode via the constructor is something I'd normally only expect to done when cloning it from a prototype such as when loading objects, in this case I'd expect the LightPointNode to be empty and then subsequent adds should then dirty it. If the LightPointNode is being copied from an already complete LightPointNode then perhaps the copy constructor of the Node that it uses is leaving the dirty flag in a false state as the node it's copying is valid.
If we are talking about an already valid LightPointNode then I guess this would be OK as long as all the data is copied - suggesting you change is sensible. The other alternative would be to call dirtyBound() in the copy constructor but if all the data is copied this won't be required. Efficiency wise it'd make more sense to copy the _bbox as you have done. Thoughts? Robert. On 22 February 2013 16:06, Chris Hanson <[email protected]> wrote: > 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 facebook.com/alphapixel (775) 623-PIXL [7495] _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
