Hi Markus, I'm in the middle of some complex work on shader support in the OSG which needs 100% of my brain capacity, once this is out of the way I'll have a look.
Others are welcome to dive in and have a look what might amiss. Robert. On 3 February 2015 at 12:55, Markus Hein <mah...@frisurf.no> wrote: > > Hello Robert and all osg-users, > > > > 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. > > > thanks, yes we lets find out what is wrong with the optimizer. > > we have made a small testmodel, reduced to a minimum, making it possible > to reproduce some issues we came across. Based on latest OSG code, if > running FLATTEN_STATIC_TRANSFORMS and REMOVE_LOADED_PROXY_NODES together > will result in misplaced Objects (in the testmodel, the lighthouse is > placed somewhere offshore.. not on land . :-) ) > > The problem only arises if: > > - there is at least one LightPointNode in the model > > > - FLATTEN_STATIC_TRANSFORMS and REMOVE_LOADED_PROXY_NODES active > > > As soon as some model is containing one LightPointNode and > DEFAULT_OPTIMIZATIONS are run - things can go wrong. This is reproducable > with the testmodel attached. > > At line 1173 in Optimizer.cpp , LightPointNodes are put in some > _excludedNodeSet in > Optimizer::FlattenStaticTransformsVisitor::apply(osg::Node& node) > At line 1114 in Optimizer.cpp , some invalid nodes are bypassed. This was > introduced lately. > At line 184 in Optimizer.cpp, rlpnv.removeRedundantNodes(); also has some > relation to our problem > > Outcommenting one of these lines (1173 or 1114 or 184) gives a result > that is correct, so I wonder what is going wrong? I could not locate the > right place where some change must be done. Maybe someone who is deeper > into Optimizer can help with this ? > > > thanks, best regards, Markus > > > > > > Right placement of the lighthouse: > > > > Wrong placement: > > > > Small simple Example, run the "AlgerExample_WithNavaid.flt" after > unzipping. > > > > > > > Den 29.01.2015 11:32, skrev Robert Osfield: > > 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 > listosg-users@lists.openscenegraph.orghttp://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 > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
