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/

Reply via email to