Hi Mathias, On 11/8/06, Mathias Froehlich <[EMAIL PROTECTED]> wrote:
> How many nodes are you updating? 10? 100? 1000? 10,000? If its under > 1000 then I wouldn't expect traversal to be a big issue. More likely > is the ops you are doing in the update traversal. In a standard scene at the default location with the default aircraft about 5000-10000. Depending on the models in the scene even more. Think that every object that moves wrt its parent - including for example the ball in the artificial horizont - is updated using such an update callback.
Ok. 5,000 to 10,000 updating objects in the scene is pretty extreme.
I have tried to replace the update callbacks that actually do anything with the plain osg::NodeCallback implementation that does nothing but return. This way we will have the same traversal node count but no meat in the callback. The update() time is roughtly (~95%) the same. That tells me that traversing is the cost not the callbacks itself. As told before this could be done more inteligent and I think we need to do so.
Well I think the scene graph you have is overly fine grained, and building it in more coarse grained way would probably be appropriate. Also consider higher level control of what parts need updating is something else you consider. For instance you could have a PlaneUpdateCallback that you attach to the top most node of aircraft. Alternatively you could just push the changes onto the scene graph once per frame taking the input directly from the simulation part of the software.
> If there are performance issues its typically down the way the scene > graph is being used. This is possible too. What are the top 10 most often made mistakes you see in your consulting job? :)
I don't have a top ten. Having a nice balanced scene graphs is crucial for cull performance, as is having the apporpriate granularity - i.e. too many small objects is inefficient on cull and draw, too many large objects is leads to ineffective culling and can stalls of the GPU. Another big one is enabling the sharing of state. There are lots of issues besides thse to be mindful when composing an efficient scene graph. There are also lots of tips and tricks you can deploy to help out. What is appropriate will depend on where you are starting from and your current bottlenecks.
The scenery tiles are relatively croase. Only about 1-20 triangles in a ball of about 20 meters around the aircraft. But thise triangles are organized in long tristrips that for example cover the whole runway or just bigger parts of the scene. So boundingbox tests are very croase. You need to enter many nodes that cover such strips to see that no triangles are in. OTOH there are some objects that are very fine. These are also in the scene and are sometimes masked out with the nodemask for the intersection test but sometimes need to be considered since people want to land their heilcopter on a roof of a building ... Some of these objects also move over time. We need to consider not only at discrete time snapshots but also at continous times in between. You would else see aircraft jumpig on a rolling carrier ... All in all I think that we need to seperate the intersection stuff from the scene stuff and place that in some bounding volume treethat can have movable nodes. Smaller objects could then be tested just with a croaser test geometry. Relevant parts can probably be simplified.
Thanks for the details. Its difficult to know what to change without being closed to the code and more familiar with the way you layout the whole scene graph. When you have a working port of FlightGear I'll download it and see if I can get it running will give me a better insight. However, I am really busy with work, so tinkering with other code no matter how curious has to take a back seat to my core duties. Things I'd suggest are putting in update, cull and draw stats is also very useful, if you can have these on screen then it'll help. Another trick is to output the scene graph to a .osg file and just look through it, looking for how balanced the scene graph is, and if certainly nodes are being overused perhaps mis-used. It may take a while to understand all the ways to get the best performance, and to evolve FlightGear to take the best effect of them. The OSG should help in this process, but just learning the basics of the OSG and porting across is no small undertaking. I have no doubt that you'll be able to get FlightGear running at a solid 60Hz, and the OSG should help you scale things up and handle bigger data and more scalable hardware. Are there developer docs on FlightGear? Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
