Hi all,
Den 22.01.2015 14:05, skrev Robert Osfield:
There isn't any way for me to know whether you have hit upon a bug or
just that the scene graph you are trying to optimize is structured in
way that could can eliminate the transforms as I simply don't have a
dataset that reproduces it. One of the things that prevent transforms
being flattened and then removed is if a subgraph has two parents each
with it's own unique transform.
I would add that the Optimizer and all it's parts is a sticky plaster
fix for bad scene graphs, it tries it's best to fix bad scene graphs
but it can't always do everything that could be done. In an ideal
world all scene graph would be built optimally in the modelling
software and never need this fix up processing.
I came across some optimizer issues and try to track down whats going
wrong. I have noticed misplaced geometry after loading some of our older
FLT databases into latest osgviewer app (using osg trunk). The problem
arises when running the optimizer with default optimizations in
osgviewer over the loades model. Following default optimizations seem to
be in conflict:
FLATTEN_STATIC_TRANSFORMS and REMOVE_LOADED_PROXY_NODES
The last change on Optimizer.cpp (revision 14388, 29. 07.2014 ) line
1102 has some impact. Without running this change our datebase doesn't
get misplaced objects. We try to make a small testdataset to be able to
reproduce the issue. Typically these databases was built with multigen,
using lots of proxy's , multiple parents, heavy use of LOD's. I try to
figure out what is the reason for that we are loosing some transform
information, I'm not sure right now. Only thing I can say is that our
models worked with the old Optimizer code.
Even if our models have a structure that is "difficult to optimize" ,
the DEFAULT_OPTIMIZATION settings shouldn't break it.
One thing that I also noticed is that converting some of our models
takes much more time and RAM than before. I could see that running
SHARE_DUPLICATE_STAE and MERGE_GEOMETRY is taking much time / RAM.
Having a small testmodel is probably the best way to solve this, we are
trying to make one that is simple, but using the same structure as used
in our databases.
regards, Markus
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
