Re: [osg-users] Effects of locale setting
Selon Robert Osfield [EMAIL PROTECTED]: I get 2 glGetString( GL_VERSION ) returns 2.0.6958 Release OK, one bit of the jigsaw. What happens to the osg::getGLVersionNumber() value if you can the locale? For instance WxWidgets changes the locale by default I believe. Hi Robert, Sorry i didn't reply sooner (i lost internet access after problematic hardware upgrade). Anyway the OpenGL version string on my machine is now 2.1.7769 In a wxWidgets-based viewer, osg::getGLVersionNumber() returns 2.1 under C, fr_FR and [EMAIL PROTECTED] locales, but returns 2 when locale is fr_FR.UTF-8 (without wxWidgets it's always 2.1). Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi David,
On Mon, Nov 24, 2008 at 9:26 PM, David Spilling
[EMAIL PROTECTED] wrote:
Only just caught this thread. I'm happy to update the OBJ plugin (reader
only, presumably) if you want to lose the sscanf, as it's only recently I
was looking at it anyway.
This would be very helpful, as I'm rather stretched right now trying
to manage all the submissions, fix bugs...
I assume that you want all sscanf(blah, %f, my_float); to be replaced by
sscanf(blah, %s, my_char); my_float=atof(my_char), more or less, or did
you want the whole thing done with std::string or something?
I was wondering if we might be able to reuse the osgDB ascii parsing
code. In particular I add a set of osgDB::Input::read(...) methods
that work like osg::ArgumentParser does in adapting generic
parameters. It means that you can do:
if (fin.read(mat,myFloat1,myFloat2)) { ... }
Or:
if (fin.read(texture,myTextureString)) { ... }
This functionality was added to osgDB in the last six months, so its
usage doesn't appear too widely in the .osg plugins yet, but it
certainly makes the task of parsing much more sane. osgDB::Input
already uses asciiToFloat/asciiToDouble.
Was the original problem (top of the thread) a recent one, as I seem to have
missed it if it was...
The .obj plugin not working when the locale is set was what pushed me
to raise this topic. Earlier I had to fix the .osg plugin to handle
this issue - but I didn't look at this as a general issue.
And sorry to be dense, but is the issue also whether OBJ writers (modelling
programs) are locale specific, and how a user might choose the OSG .obj
plugin to respect locale or assume a default?
For file formats my guess is that none will use a non default locale,
i.e. '.' will always be the decimal place. The only way for this to
not be the case would be where file formats explicitly declare the
locale that the format is in, but I don't know of any formats that we
load that do this.
Robert.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Robert, Only just caught this thread. I'm happy to update the OBJ plugin (reader only, presumably) if you want to lose the sscanf, as it's only recently I was looking at it anyway. I assume that you want all sscanf(blah, %f, my_float); to be replaced by sscanf(blah, %s, my_char); my_float=atof(my_char), more or less, or did you want the whole thing done with std::string or something? Was the original problem (top of the thread) a recent one, as I seem to have missed it if it was... And sorry to be dense, but is the issue also whether OBJ writers (modelling programs) are locale specific, and how a user might choose the OSG .obj plugin to respect locale or assume a default? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Robert, I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL pointer. Something you already encountered ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html ). I can't answer your question then, sorry. (Or maybe you know how to avoid this NULL pointer?) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ [...] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Robert; I have same problem as Sukender and set OSG_NOTIFY_LEVEL = DEBUG and result is as follows; glVersion=2, isGlslSupported=YES, glslLanguageVersion=1.1 Regards. 2008/11/24 Robert Osfield [EMAIL PROTECTED] Hi Sukender, You can only call getGLVersionNumber() or any releated OpenGL from a thread with a valid graphics context - there is nothing the OSG can do about this - it's a characteristic of OpenGL. The locale issue does change this. Running osgviewer will call getGLVersionNumber() when it runs, so running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the results of all the extension checks, I'm not sure in the OpenGL version number is amongst these. osgviewer doesn't set the locale though So perhaps osgviewerWX would be a better base. Robert. On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote: Hi Robert, I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL pointer. Something you already encountered ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html). I can't answer your question then, sorry. (Or maybe you know how to avoid this NULL pointer?) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ [...] 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 ___ 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 -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Umit, Which is the OpenGL version string you have on your machine? Robert. On Mon, Nov 24, 2008 at 9:57 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Hi Robert; I have same problem as Sukender and set OSG_NOTIFY_LEVEL = DEBUG and result is as follows; glVersion=2, isGlslSupported=YES, glslLanguageVersion=1.1 Regards. 2008/11/24 Robert Osfield [EMAIL PROTECTED] Hi Sukender, You can only call getGLVersionNumber() or any releated OpenGL from a thread with a valid graphics context - there is nothing the OSG can do about this - it's a characteristic of OpenGL. The locale issue does change this. Running osgviewer will call getGLVersionNumber() when it runs, so running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the results of all the extension checks, I'm not sure in the OpenGL version number is amongst these. osgviewer doesn't set the locale though So perhaps osgviewerWX would be a better base. Robert. On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote: Hi Robert, I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL pointer. Something you already encountered ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html ). I can't answer your question then, sorry. (Or maybe you know how to avoid this NULL pointer?) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ [...] 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 ___ 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 -- Ümit Uzun ___ 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
Re: [osg-users] Effects of locale setting
Hi Robert, I don't know if I did what you expected, but my GL string is always 1.4.0 - Build 7.14.10.4926 and OSG always reports glVersion=1.4, isGlslSupported=NO, glslLanguageVersion=0 on the console even if I call setlocale(LC_ALL, FR_fr); or EN or C at the begining of main(). Please not that I my LANG env variable is set to FR and that French decimals should be separated with ','. Is that enough info for you? Or should I run another test? Hope it helps. However, the strange thing is that I can't run GLSL in OSG, but the Spring (XTA) game has shaders that run on my machine and, well I'm not THAT sure, but I think it also uses GLSL since the reflective water shaders are .glsl files and that I can see the effects in the game. Anyone knows more about Spring and GLSL? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 24 Nov 2008 10:19:39 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: Hi Sukender, You can only call getGLVersionNumber() or any releated OpenGL from a thread with a valid graphics context - there is nothing the OSG can do about this - it's a characteristic of OpenGL. The locale issue does change this. Running osgviewer will call getGLVersionNumber() when it runs, so running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the results of all the extension checks, I'm not sure in the OpenGL version number is amongst these. osgviewer doesn't set the locale though So perhaps osgviewerWX would be a better base. Robert. On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote: Hi Robert, I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL pointer. Something you already encountered ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html ). I can't answer your question then, sorry. (Or maybe you know how to avoid this NULL pointer?) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ [...] 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 ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hum... forget about the Spring shaders, I found some .fp files (ARB fp ???) that describe water effects. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 24 Nov 2008 11:42:13 +0100, Sukender [EMAIL PROTECTED] a écrit: Hi Robert, I don't know if I did what you expected, but my GL string is always 1.4.0 - Build 7.14.10.4926 and OSG always reports glVersion=1.4, isGlslSupported=NO, glslLanguageVersion=0 on the console even if I call setlocale(LC_ALL, FR_fr); or EN or C at the begining of main(). Please not that I my LANG env variable is set to FR and that French decimals should be separated with ','. Is that enough info for you? Or should I run another test? Hope it helps. However, the strange thing is that I can't run GLSL in OSG, but the Spring (XTA) game has shaders that run on my machine and, well I'm not THAT sure, but I think it also uses GLSL since the reflective water shaders are .glsl files and that I can see the effects in the game. Anyone knows more about Spring and GLSL? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 24 Nov 2008 10:19:39 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: Hi Sukender, You can only call getGLVersionNumber() or any releated OpenGL from a thread with a valid graphics context - there is nothing the OSG can do about this - it's a characteristic of OpenGL. The locale issue does change this. Running osgviewer will call getGLVersionNumber() when it runs, so running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the results of all the extension checks, I'm not sure in the OpenGL version number is amongst these. osgviewer doesn't set the locale though So perhaps osgviewerWX would be a better base. Robert. On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote: Hi Robert, I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL pointer. Something you already encountered ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html ). I can't answer your question then, sorry. (Or maybe you know how to avoid this NULL pointer?) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ [...] 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 ___ 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 ___ 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
Re: [osg-users] Effects of locale setting
Robert Osfield wrote: 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()). The OpenGL spec specifies that the return value of glGetString(GL_VERSION) should begin with major_number.minor_number[.release_number], so if the results are locale-dependent and suddenly use a comma instead of a period that's clearly a bug in the drivers. Or am I misunderstanding your question about the returned OpenGL version string? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Robert, My OpenGL version string only 2. I can only see the major version number. I have OSG-2.6.1 on XP SP2. HTH.Regards. 2008/11/24 Paul Melis [EMAIL PROTECTED] Robert Osfield wrote: 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()). The OpenGL spec specifies that the return value of glGetString(GL_VERSION) should begin with major_number.minor_number[.release_number], so if the results are locale-dependent and suddenly use a comma instead of a period that's clearly a bug in the drivers. Or am I misunderstanding your question about the returned OpenGL version string? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Paul, On Mon, Nov 24, 2008 at 10:51 AM, Paul Melis [EMAIL PROTECTED] wrote: The OpenGL spec specifies that the return value of glGetString(GL_VERSION) should begin with major_number.minor_number[.release_number], so if the results are locale-dependent and suddenly use a comma instead of a period that's clearly a bug in the drivers. Or am I misunderstanding your question about the returned OpenGL version string? Thanks for the clarification. This tells us that we should use my asciiToDouble/Float functions in the OpenGL query code to avoid locale issues with atof. I will do a purge of the OpenGL related atof functions. It'll be interesting to see where problem points may have been, I'll ping this thread once these changes are checked in. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi All, On Mon, Nov 24, 2008 at 11:41 AM, Robert Osfield [EMAIL PROTECTED] wrote: I will do a purge of the OpenGL related atof functions. It'll be interesting to see where problem points may have been, I'll ping this thread once these changes are checked in. I have now converted the OpenGL related atof usage across to using the osg::asciiToFloat function instead, this is now checked into svn. There are other places in the OSG that use atof, some main be appropriate to leave as being locale sensitive, others I think it would be best to convert to use osg::asciiToFloat/asciiToDouble. The big question which ones... The files that still use atof are: parsing env vars/ReaderWriter::Options: -- ./osg/DisplaySettings.cpp ./osg/CullSettings.cpp ./osgDB/DatabasePager.cpp ./osgGA/DriveManipulator.cpp ./osgViewer/ViewerEventHandlers.cpp ./osgPlugins/ive/DataOutputStream.cpp ./osgPlugins/txp/ReaderWriterTXP.cpp ./osgPlugins/txp/TXPParser.cpp ./osgPlugins/normals/ReaderWriterNormals.cpp command line argument parsing: -- ./osg/ArgumentParser.cpp file parsing: -- ./osgPlugins/x/types.cpp ./osgPlugins/dw/ReaderWriterDW.cpp ./osgPlugins/cfg/ConfigParser.cpp -- All the file parsing code I think should be converted across to asciiToFloat as these formats won't be explictly defining which convention they use so one can't decide based on that particular file - one has to assume a single interpretation on all files and the standard '.' decimal place will the one used. The env var/options and command line parsing are OSG specific, and will be developer dependant, so if the user is consistent themselves and set the locale to be consistent with this then they could probably safely use either convention, however, there quite a bit of scope for the locale to not be set at all times and on all platforms the same (i.e. different end users will install on different platforms so locale will vary), so my inclination is formal decide to use the '.' decimal place convention for all OSG env vars/options and command line parsing, and following on from this use osg::asciitToFloat for all these parsing methods. Thoughts everybody? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
I was curious why the .obj plugin that parsing ascii files didn't come up on my searches for atof usage, and the reason is that the code uses sscanf for reading the files. This means that it's a bit more complicated to solve, I can't just do a search and replace... What the code will need is either an explicit local setting in the plugin and later restore of it's value or porting the code across from using sscanf to a locally defined equivalent. I don't know the situation w.r.t thread safety of setting/restoring locale setting, as our plugins can be used in background threads it's an important area to clear up. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Effects of locale setting
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
Re: [osg-users] Effects of locale setting
Selon Robert Osfield [EMAIL PROTECTED]: 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()). I get 2 glGetString( GL_VERSION ) returns 2.0.6958 Release Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Effects of locale setting
Hi Micahael. On Sun, Nov 23, 2008 at 3:20 PM, [EMAIL PROTECTED] wrote: Selon Robert Osfield [EMAIL PROTECTED]: 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()). I get 2 glGetString( GL_VERSION ) returns 2.0.6958 Release OK, one bit of the jigsaw. What happens to the osg::getGLVersionNumber() value if you can the locale? For instance WxWidgets changes the locale by default I believe. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
