Bound computation should take VAO ptr

[GoogleCodeExporter]

Bound computation requires the address of a VertexArrayObject so that vertex 
data can be used to compute the bound. Currently, bound computation takes a 
CommandMap pointer, and this will not work properly when CommandMap objects are 
allocated dynamically on the stack, as it would defeat caching in a map indexed 
by the address.

Original issue reported on code.google.com by SkewMat...@gmail.com on 6 May 2013 at 9:30

[GoogleCodeExporter]

This is not a trivial problem. Ideally, each Drawable and Node needs to keep a 
map of bounds indexed by VAO address. This map would get populated at 
collection (cull) time. If multiple collection/cull threads are operating 
concurrently, we would need some kind of lock just to look up a bound. We need 
to measure the performance impact of such a scheme, and if it's too expensive, 
we need to reconsider the decision to have VAO as a part of state.

Original comment by SkewMat...@gmail.com on 7 May 2013 at 3:11

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by abry...@gmail.com on 17 Jun 2013 at 8:46

• Added labels: Milestone-DA2013

[GoogleCodeExporter]

Taking the CommandMap as a param in jagSG::Node::getBound() is OK for now, as 
the CommandMap gets accumulated during a traversal by VisitorBase.

However, current code has been modified so that computation of Drawable bounds 
takes a VAO as a param. Currently that is a jagDraw::VertexArrayObjectPtr, 
which is a boost shared_ptr, but this could be a raw C ptr and thus avoid the 
shared_ptr constructor overhead.

However, the spirit of this issue is currently resolved: Both jagDraw::Drawable 
and jagSG::Node keep a map of VAO address to BoundInfo (bounds and a dirty 
flat), and the map access has a lock around it.

Although there is room for future code cleanup and other enhancements, this 
issue is resolved.

Original comment by SkewMat...@gmail.com on 26 Jun 2013 at 9:57

• Changed state: Fixed