Hi Paul, On 1/19/07, Paul Martz <[EMAIL PROTECTED]> wrote:
Agreed, the performance hit of something like this would be astronomical. This would have to be something that has zero impact when disabled.
Just having a check to see its enable would also have a performance hit, which is why I favour reusing the node callbacks for this type of user stats.
> Their are also practical limits to the type of stats you can > collect - for instance nodes can have their update and cull > times caught by a NodeCallback, but you can't collect draw > stats as Node don't have anything to do with the draw > traversal - its only Drawable and StateSet's. Not possible in the current implementation, correct. It would have to be redesigned to support it. If the RenderGraph were made smart about which Node/Geode owned the Drawables/StateSets referenced in the RenderGraph, then draw traversal timing stats could be fed back from the RenderGraph to the appropriate scene graph nodes.
As the subgraph below single node can end up contributing to a wide range of drawables, stateset and RenderBins, I believe its impractical to trackle this as the design and implementation would be complex to develop and matintain and any such framework would have a performance hit even when sitting iddle as one would need to check to see if you need to populate the associate structures. If users want to track timings of indivual drawables and stateset then this is more doable but again I'm not about to go adding extra infrastructure that holds back performance. I'm happy to allow users to add NodeCallbacks or Drawable callbacks as these are already part of the workload. Added the possibility of stats collection at the RenderBin level also needn't be too intrusive in performance or current data structures. My assumptions on granularity are that users will have modest number of cameras and render bins working each frame so extra checks and stats logging will be not be too expensive. However, there may well be 10's or 100's of thousands of nodes and drawables in the scene graph and thousands of drawables/stateset/stateattributes needing traversed in the RenderBin's, this level of granularity is fine enough that add any extra ops to each drawable/stateset/stateattribute will have a real detrimental effect and so should be avoided. Robert. _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/