Hi Robert,
> I really can't comment without the actual problem and solutions in> front of
> me, it's just too complex a topic to accumulate a whole> thread and then
> generate in my head what the possible code and scene> graph you have going on
> at your side.> > One thing I can say is that the number of nodes you are
> playing with> looks pretty excessive. I have no clue what type of application
> you> have and what you are trying to do, but there may well may a wholly>
> better way of tackling your problem than throwing a massive scene> graph at
> it.>
Ok, I'll explain what we are doing :-)
We are creating a simulator for vehicles, people and combat. A typpical world
that we display is 15000x15000 meters. The terrain is populated with cities,
roads, light-poles at the side of the road, lots of forests, lots of stones
laying around in the terrain and other debree. The example I tested with is
actually quite simple compared to what we will need to use. We are going to
show a realistic sea that use GPU side vertex displacement from a real-time
generated height-map for waves. The water surface will reflect the world and
refract the sub-sea terrain. We are going to add shadows and volumetric fog.
The combat scenes will use an extensive ammount of particles. The complexity
level is high both on what we demand of our shaders and for the detail of items
in the world. We are also considering implementing deferred lighting. Our
simulators will be possible to configure to run low detail if the customer
chose to use a graphics card that is not too powerful, and high detail if the
customer wants to spend money on high end hardware.
The complexity of this demands a good system for shaders. We must LOD the
geometry in the world and also LOD the shaders we apply onto them. Rendering
one frame image of our scene requires multiple pre-rendering cameras and some
times multiple post-rendering cameras. Our world is so large that we will
re-use the node-tree for all the cameras and use the node masks to determine
what to render.
We test performance on small scenes and on large scenes. The size of the scene
used in an example does not neccessarily matter when you are discussing a
specific technology/problem. I tested both approches on one palm-tree instead
of the whole world. It too has a similar initialization time problem, but it is
so small that it is hard to measure it properly. Other computer activities will
disturb too much (we are talking Windows, and Windows does not handle
multitasking in the best possible way) :-) So, in this case, throwing a large
scene at the problem make a lot of sense, the numbers stand more out this way.
I am so far impressed by the speed and useability that OSG provide. OSG is a
very good engine. It is great to work with it.
I am going to run a profiler on the initialization problem. That is probably a
great way of figuring out where the time goes. Perhaps also do a single-step
journey into the run function to see what it actually do.
Have a nice weekend,
Viggo
_________________________________________________________________
Mest sett denne måneden på MSN Video.
http://video.msn.com/?mkt=nb-no&from=HMTAG
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
