Hi,
On Wed, 2010-06-23 at 18:20 +0800, Gerrit Voß wrote:
> Hi,
>
> On Wed, 2010-06-23 at 09:49 +0200, Johannes Brunen wrote:
> > Hello,
> >
> > I'm working on OpenSG 2.0 r2449. I have written a simple file w1.osg
> > with
> > bool ret = SceneFileHandler::the()->write(node, "w1.osg", false);
> >
> > Reading it back by
> > NodeUnrecPtr prototype = SceneFileHandler::the()->read("w1.osg", NULL);
> > does not work as expected. This can be seen by the result of
> > subsequentially writing of the prototype node:
> >
> > bool ret = SceneFileHandler::the()->write(prototype, "test_1.osg",
> > false);
> >
> > I have uploaded the files to
> > http://drop.io/OpenSG_RenderEngine
> >
> > I tried to debug it, but was stuck by a call to
> > OSGScanParseSkel_parse(this);
> > which I could not resolve.
> >
> > Could anyone take a short look what is happening on loading of this file
> > format. I think (with some uncertainty) that I have tested this format
> > with a former revision. Beside, file format '.osg' is working fine.
>
> one problem I can see when loading w1.osg is that the clip plane chunk
> beacons are not quite correct. While loading the cores of the nodes are
> set to NULL. I'll have to check why this happens.
>
> Initially I had the problem that there is a GeoToEntityAttachment which
> I guess is a custom container of your application. Which does not load
> correctly.
>
> Otherwise your file seems to load and re-export fine using
> testWindowGLUT.
>
> test_1.osg looks more like the loader is failing quite early.
>
> I still have to check the particular revision you use.after making two minor changes, remove the artificial node level the osg loader introduces and to handle the name attachment correctly while writing, I get the attached diff when reading and writing the file (w1.osg) with testWindowGLUT (r2449). I will push the changes to the latest version. Assuming still have the problems could you run your test program with OSG_LOG_LEVEL=10 and sent me the output. And maybe try it with testWindowGLUT (the writing is disabled by default with #if 0). That the beacons have a node but no core is a bug inside the writer which can access and object even if there is only a weak reference left. While running the system itself sees no beacon. kind regards gerrit
46c46,62
< attachments [
]
---
> attachments
> [
> MapHelper
> {
> keys
> [
>
> "0"
> ]
>
> container Name
> {
>
> name "GeoUInt32Property458"
>
> internal FALSE
>
> attachments [ ]
> }
>
> }
> ]
157,177d172
< # MapHelper
< # {
< # keys
< # [
< # "0"
< # ]
< # container
GeoToEntityAttachment
< # {
< # Ent #6
< # [
< #326047744, 326047360, 326046528, 326046080, 326046976, 326048128
< # ]
< # Geo #6
< # [
< #4, 8, 12, 16, 20, 24
< # ]
< # internal
FALSE
< # attachments
[ ]
< # }
< #
< # }
247,251c242
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
268,272c259
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
289,293c276
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
310,314c293
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
331,335c310
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
352,356c327
< core
Transform
< {
<
matrix 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
<
attachments [ ]
< }
---
> core
> NULL
------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
