Hi there, thanks for your quick input. @Robert; The use case is pretty common: the original model assumes mm, I assume meters. Hence the extreme scaling. Yes I noticed the transforms are flattened, which is probably a good thing in my case but it shouldn't change the rendering. (The model is exported by a 3rd party software so I don't have full control)
@Sebastian: Yes you are probably right, I thought that some normals were completely lost though due to the scaling (rescaling = division by 0) but maybe I was lucky this time. Thanks again, Per On 4 December 2017 at 10:38, Sebastian Messerschmidt < [email protected]> wrote: > > > Hi Per, > > Just a thought: > Maybe the Optimizer simply applies normal-rescaling? > > Cheers > Sebastian > >> Hi all, >> >> I came across something strange recently; >> the attached model is a red triangle scaled down by a factor 1000. >> The normals are squashed and I see some rendering problems in my app, >> which uses osgcompositeviewer. >> >> Confirmed with >> osgcompositeviewer red.osgt - renders with white color (incorrect) >> BUT >> osgviewer red.osgt - renders with red color (correct) >> >> I did some digging in the OSG code, it seems the difference is that >> osgviewer always >> optimizes the scene graph, something that osgcompositeviewer never does. >> Adding an optimizer to osgcompositeviewer fixes the rendering. >> >> So first question; would it be better if the two viewers applied same >> optimizer settings? >> Since users would expect them to display things in the exact same way. >> >> Second and more interesting; how can optimizer correct a "broken" model? >> >> Thank you! >> >> /Per >> >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >>
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
