HI Michael, This issue you have doesn't look to be related to the parent thread so fixes suggested on that thread are unlikely to be relevant.
As to what might be wrong in your case it's not possible to say without having the model in front of me to look at and reproduce the problem. The best I can suggest would to look at the differences in the .stl plugin between OSG-3.0.x and OSG-3.2.x to see if there are any differences there. Also try running the model in osgviewer, is this possible to reproduce the issue? Another thing you could try is to run osgconv on the original .stl to generate a .osgt or .osg file using osgconv from 3.0.x and then 3.2.x to see if the differences are apparent. If it does turn out to be the case that the .stl plugin isn't setting state it should be setting so is inheriting random state from elsewhere in the scene graph then it'd be appropriate to add that missing state to the plugin. However, this is just speculation, I don't know enough information to know the actual cause. Robert. On 23 October 2014 03:33, Michael Grey <[email protected]> wrote: > Hi, > > I'm running into an issue that I think is related, but not exactly the > same. > > Prior to the 3.2 release, I could load an .stl file using the > osgDB::readNodeFile(~) function, and it would come out looking like a > diffuse white material. Presumably this was just a default setting > somewhere in OSG or OpenGL, because the .stl file doesn't encode color or > material properties. > > In the latest release, the file gets loaded as a shiny golden color > (attachment "A"). > > I tried applying setGlobalDefaults() to the Viewer's Camera, but this had > no effect. I also tried applying setGlobalDefaults() to the node which gets > generated from osgDB::readNodeFile(~), and this changed the golden color to > a blackish color (attachment "B"). > > I found that I could crawl through the auto-generated node and parse out > its geodes and geometries, then change their color array to whatever I > want. I imagine I could do something similar with their materials to get > rid of the shininess. However, this is a problem for two reasons: (1) It's > annoying, and more importantly (2) If some color/material properties are > loaded from the file, I don't want to overwrite them. > > I'd really just like a way to get back the behavior prior to 3.2 where a > loaded node would have some reasonable default rendering properties if the > properties aren't provided by the file that's being loaded. > > If anyone has suggestions for how I might be able to accomplish this in a > robust way, I would greatly appreciate it! I suspect there's probably some > stupidly simple thing I could do that I'm just not aware of because of my > inexperience with OSG. > > Thanks! > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=61381#61381 > > > > > Attachments: > http://forum.openscenegraph.org//files/dark_robot_376.png > http://forum.openscenegraph.org//files/gold_robot_174.png > > > _______________________________________________ > 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
