Hi Markus, Absolutely the Optimizer shouldn't break scene graphs, it should only replace with scene graph elements that reproduce the same result, if it doesn't then there is a bug in either the transformations or applying modifications where none should be.
W.r.t. model size growing after, typically it goes down, including when optimizing OpenFlight databases. If it's taking more memory it could be a bug, or inappropriate operations being applied. I can't say anything specific though, as I don't have the data, I simply don't know what might be amiss. Robert. On 29 January 2015 at 10:05, Markus Hein <mah...@frisurf.no> wrote: > 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 >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
