Hi All, In response to problems with the obj loader when the c local is set to one that use comma for the decimal place (same problem previously affected the .osg) I have begun make the custom atof function I wrote for the .osg plugin as public function of osgDB so it could be used else where. This then brought me to ask the question how widely should I roll out this new osgDB::asciiToDouble/asciiToFloat(..) function.
The key question is how widely the data formats that users will be reading, .osg, .obj are starters as this as ascii formats. What about others like COLLADA files, or even version strings and env vars that users set themselves. If you know what local the data you are reading is in then you can use what is appropriate, but this could change for machine to machine, user to user. There are some constraints for certain formats - like .osg does write out only in the standard locale format, so we know always to read it with the same locale. Is .obj always going to be the same? What about OpenGL version strings? The OpenGL version string is an interesting one, because I suspect it'll always be reported in the standard local i.e the OSG version number being 2.1 rather than 2,1. The could be an issue if the locale is set so that atof only looks for 2,1 but then reads 21... or would that be 2. Which ever way it'd be wrong and we could be getting wrong behaviour. So... could users who's machine are set up for a locale that uses the command convention for decimal places please post what results they get for the OpenGL version string, and what the OSG parses this string to be (i.e. the result of osg::getGLVersionNumber()). Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
