Tim,
On Tuesday 08 May 2007, Tim Moore wrote:
> >> There is also a second assumption in the animation system: The textures
> >> for the liveries are expected not to be in the osg::Drawables. That is
> >> not always true and is especially no longer true with the ac loader
> >> update in osg svn since a few days.
>
> I don't think the material animation makes that assumption. It overrides
> the texture attribute, so any textures in nodes below, even in
> Drawables, are ignored.
Not with the material animation, but the animations system model loading
system ...
That assumption is made with the liveries.
We take an already loaded model that is cloned except the drawables and
textures to share the display lists and textures.
Then there is a visitor that walks the texture attributes and checks if the
loaded image is the same than the one in the current livery load path. If
that does not match it replaces the texture attribute with the one with the
correct livery texture. Then osgDB walks again over the tree and collapses
the textures again to a single one that is also shared with other models if
it is the same.
If this happens on any StateSet attached to a cloned Node this works well. But
if this happens on a StateSet attached to a shared drawable, it will change
all models except only the single one the livery is meant for ...
> >> The problem that is fixed here, which is also in the past and current
> >> material animation to some degree, is that render bin numbers in osg
> >> build hierarchical render bins. That means we should only put render bin
> >> numbers at drawables or on nodes that have well known leafs.
> >> With that change the transparencies are handled way better with osg.
>
> You're a lot more familiar with the problem than I. Do you get the
> undesirable hierarchical behavior if the states sets in the drawables
> inherit their render bins?
No, if they inherit this is ok. But if they inherit, you cannot set anything
new to them ...
That is also a powerful tool, but that is the one I struggled at most with.
It became clear at the time Robert visited us in Tübingen and told that ...
> When you load a model, you get a prototype that you will copy, if
> necessary, for its instances. Ideally you should only copy
> Transformation nodes for animated parts; if materials are animated, the
> nodes that hold the animated material should be copied too. Ideally you
> share entire state sets, not just the texture.
That would be nice.
I am not sure if it is worth it.
What do you gain here?
The osg::State can collapse the state sets a little more efficient since it is
already finished if the pointers to the state sets are compared and match. It
does not need to look into the StateSets' attributes and modes.
I have played with that at some stage and did not see any improvement.
There is not much more than the dlists and the textures that can be shared
efficiently in the GPU in the StateSet (well, the shaders, but leave them
away for now).
But I think it complicates current and future animation work.
>From the animations system I think it is best that you can assume to work an
an already private tree. You have to think much about the side effects of
first applying that animations, leading to some partial private tree and than
applying the other one, leading to whatever.
Group, Transforms and all that stuff is not that memory intensive in main
memory that it is worth the effort. Also in the GPU these cannot be shared.
To ease the job for animation programmers I think of some normalization of the
scenegraph.
Proposal:
Lift and StateSet's in Drawables into the Geodes introducing new geodes if
necessary. That means Drawables do not have textures attached to it and can
be shared over more models. Then still clone everything in a model except
that StateAttributes and Drawables (dlists) that are shared in the GPU for
efficiency.
I believe that we gain most flexibility with private trees without loosing
efficiency.
BTW: my last patch to the ac3d loader delivers that type of trees. But loaders
cannot be assumed to work like that ...
> There's no reason not to share the geode too.
> Also, you really want to share StateSets if possible, because OSG will
> order all the drawables by StateSet to avoid state changes, but it
> doesn't look inside StateSets to minimize state changes.
No, it does not order by state. You can configure that in the render bin, but
the sort function does nothing. Look into the code. Robert told me that he
has played with that for some time, but state sorting does not gain more in
state changes than you loose with the sorting step ...
So, sharing the StateSet's does not gain too much.
If you want to manage the complexity of partial tree sharing feel free to do
so. But my feeling (and experience) is that you do not gain anything from
that.
We have other cpu hogs where we can gain much more ...
> Yes, though this sharing can either be a literal sharing of materials
> down in the StateSets of a drawable, or by inheritance of a StateSet
> higher up in the scene graph.
Well the inheritance is where we must be careful. Since StateSets can have
render bin details set. Remember that you may create hierarchical render bins
when moving StateSets partially upwards.
There are situations where this does not hurt, but transparency sorting
happens separate in each hierarchy ...
Greetings
Mathias
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
