Hi Viggo,

Thanks for the explanation.  I don't think your needs are particular
different from most who are writing games/simulators with the OSG.
While large scenes LOD's is crucial, and for massive scenes Paging is
also crucial.  The OSG supports both so should scale to larger scenes.

The other approach you could take is having custom nodes or drawables
that wrap up a the whole rendering of a class of object, or a how
collection of objects.   The later is something would suit
trees/forests.

These approaches would all reduce the number of objects in your scene
graph in memory and in the view frustum on each frame and thereby cut
the update, cull and draw dispatch costs.   If your switch node helps
in keeping the number of objects down then thumbs up for it.

W.r.t init time, typically this is pretty low.  Shaders can be
expensive.  Texture objects and drawables aren't typically too
expensive - the osgmemorytest example illustrate this.

Robert.

On Fri, Nov 21, 2008 at 3:02 PM, Viggo Løvli <[EMAIL PROTECTED]> wrote:
> 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
>
>
>
>
>
> ________________________________
> Windows Live Messenger på mobilen. Hold kontakten hvor som helst når som
> helst.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to