[osg-users] osgviewerQT, qt4.4.0 and .osg file
Johan Nouvel
I'm on Unbuntu 8.04, and I have problem with osgviewerQT (osg 2.5.0) and qt 4.4.0 when loading osg file.
Either I view nothing (for osgcool.osg), or a strange degraded model without light, without texture, with not all faces
(for cow.osg).
It works with osgviewer and it works with osgviewerQT and qt4.3.4.
More, it works with ive file and .3ds file so it seems not to be an OpenGL context/initialization trouble
I have looked in osgdb_osg but all data are well parsed.
Have someone ever see this problem ? Does someone know the solution ?
Thanks,
Johan.
--
Johan Nouvel, R&D Project Manager
http://www.archivideo.com
tel : +33 (0)2 99 86 30 20
ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Robert Osfield
Could you send a screen shot of the problem?
Robert.
Johan Nouvel
There are 2 snapshots of cow.osg (one is the initial side view, the other one is a view from above). As I have wrote, if
I osgconv cow.osg in cow.ive and load cow.ive, everything is OK. Same things for cessna.osg (2 snapshots joined).
In case of osgcool.osg, I see nothing, only the background.
I will look deeper into the code, but any clue will be helpful.
Thanks,
Johan.
Robert Osfield a écrit :
Robert Osfield
Great, a pictures saves a thousand words! The problem looks the same
as others have encountered when WxWidgets modifies the C local such
that atof switches from treating . and , as decimal points. My guess
the later version of Qt is doing the same. We've tried several
different attempts in the past to insulate the OSG from this change in
local but weren't able to come up with a workable solution. The
conclusion back then was that we might would need to use a custom atof
method, this hasn't been developed yet though.
Robert.
Johan Nouvel
Bingo ! I've modified Geometry.cpp to print out vertices before and after modification by osg::Field::getFloat and the
result is a troncation of the float, only integer part is interpreted. You're right.
What is the complexity of coding custom atof ?
Is the hypothesis that '.' is a separator ? It means also controling osg output to write a '.' instead of ','.
Or do you prefer that osg file can be with a ',' or a '.' as integer/decimal separator ?
In first, I will see how to force QT local to C.
But if I it is not to heavy to do custom atof, I'll try to do it as I think this way is better.
Thanks a lot.
Robert Osfield
On Thu, Jul 10, 2008 at 10:22 AM, Johan Nouvel
<opensce...@archivideo.com> wrote:
> Bingo ! I've modified Geometry.cpp to print out vertices before and after
> modification by osg::Field::getFloat and the result is a troncation of the
> float, only integer part is interpreted. You're right.
>
> What is the complexity of coding custom atof ?
It's not too complex, there is already some code in osgDB that
verifies floats fields as part of .osg parsing. This code could
probably be adapted. It's just another tasks on that requires some
time, and I'm rather overstretched. Others are welcome to dive in a
code a solution.
> Is the hypothesis that '.' is a separator ? It means also controling osg
> output to write a '.' instead of ','.
> Or do you prefer that osg file can be with a ',' or a '.' as integer/decimal
> separator ?
If we don't control the output and input to be just be '.' then we'd
need to store the local along with the .osg file itself. I'd be
inclined to standardise on . as the decimal place as this is the
standard throughout most of the world.
> In first, I will see how to force QT local to C.
> But if I it is not to heavy to do custom atof, I'll try to do it as I think
> this way is better.
We might have to look at writing and well as read. Setting the local
would need to be done before any write to .osg or read from .osg.
Robert.
Norman Vine
>
> Bingo ! I've modified Geometry.cpp to print out vertices
> before and after modification by osg::Field::getFloat and the
> result is a troncation of the float, only integer part is
> interpreted. You're right.
>
> What is the complexity of coding custom atof ?
> Is the hypothesis that '.' is a separator ? It means also
> controling osg output to write a '.' instead of ','.
> Or do you prefer that osg file can be with a ',' or a '.' as
> integer/decimal separator ?
>
> In first, I will see how to force QT local to C.
> But if I it is not to heavy to do custom atof, I'll try to do
> it as I think this way is better.
GDAL had a similar issue
Here is their custom atof() with some discussion of the issues
http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_strtod.cpp
Norman
Johan Nouvel
Thanks for the link.
With GDAL way, no need for controlling the output, it's during the reading phase that conversion in done
To resume :
1- searching local decimal separator
2- replace separator character into input string
3- convert string using standard method (atof for example)
Step 1 could be done at initialization time.
Steps 2 and 3 should be done each reading. The overhead is only step 2, as step 3 must be and is already called.
As far as I known, only osgDB::Field should be changed, for getFloat and calculateFieldType methods.
With only this, reading an osg file will work regardless of locale.
Robert and others :
I'm right ? Do you think it worth the effort ? Forgot something ?
Johan.
Norman Vine a écrit :
> GDAL had a similar issue
>
> Here is their custom atof() with some discussion of the issues
> http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_strtod.cpp
>
> Norman
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Johan Nouvel, R&D Project Manager
http://www.archivideo.com
tel : +33 (0)2 99 86 30 20
ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE
_______________________________________________
Robert Osfield
I believe what we'd need to do is just enforce the rule that .osg
files all use . for their decimal places, then constrain the writing
and reading of .osg files so that it uses this convention. Reading is
more straight forward, as it'd just require a modification to
Field::getFloat() method and would certainly be a useful first step.
Robert.
Robert Osfield
I have now written an osg_atof function and placed this in
src/osgDB/Field.cpp, this is now used in the Field::getFloat methods
that the .osg plugins uses. This new function always assumes that a
'.' is a decimal place.
Could you do an svn update and let me know if it works fine.
Cheers,
Robert.
Robert Osfield
On Fri, Jul 18, 2008 at 12:07 PM, Robert Osfield
<robert....@gmail.com> wrote:
> I have now written an osg_atof function and placed this in
> src/osgDB/Field.cpp, this is now used in the Field::getFloat methods
> that the .osg plugins uses. This new function always assumes that a
> '.' is a decimal place.
>
> Could you do an svn update and let me know if it works fine.
Could you also check the writing to a .osg file as well as loading
existing .osg files. The .osg plugin already has code to set the
local to classic of the std::stream's used, so in theory it should
work OK, but I'd like confirmation before I tick this problem off as
being solved.
Cheers,
Robert.
Johan Nouvel
It works ! For reading and writing .osg.
I've done a full osg checkout (version 2.5.5), then I've compiled and tested osg with a modified version of osgviewerQT
(only to write .osg file). All works.
To be absolutely sure, I've re-compiled and re-executed my osgviewerQT version with osg2.5.0 and once again I have the
truncation problem (for reading and writing .osg)
Thanks a lot.
Johan.
Robert Osfield a écrit :
--
Johan Nouvel, R&D Project Manager
http://www.archivideo.com
tel : +33 (0)2 99 86 30 20
ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE