-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mathias Fröhlich wrote: > 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 materials animation code doesn't care where textures might be in the scene graph below an animated node: I assume that if a material animation specifies a texture, it should take precedence over any textures that were loaded with the model.
>>>> 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 ... > You can't set the render bin, but you can set any other attribute or mode in the StateSet. If that causes the StateSet to change its opacity, well, that's a problem. > 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? > I don't know, but you asked how to efficiently share models :) > 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). There is a savings on the CPU in terms of memory and cache pollution. Are we talking only about aircraft models here, or models that might be instantiated thousands of times in the scene? As an aside, I think there may be an advantage on current hardware to sharing vertex data between drawables and using primitive sets within each drawable. > > 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. > Sounds good. > 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. I didn't mean that OSG sorts by details of the state inside the StateSet, but it does group drawables by StateSet i.e., the pointer to a StateSet. That is the purpose of the StateGraph code. > 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 ... > True enough :) >> 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 ... Anyway, enjoy your Sunday :) Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTrGTeDhWHdXrDRURAuhRAJ9vI6SCXwHHaIKYiX25f8C4M+MrWQCfTP49 n1/dRC/cpBwrAAKot7OFw9c= =nkz3 -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
