Hello Johannes,
Johannes Brunen wrote:
> "Carsten Neumann" <carsten_neum...@gmx.net> schrieb im
> Newsbeitrag news:4c49d799.7090...@gmx.net...
>> ok, thanks. Honestly I'm a bit overwhelmed with all the files...
>>
> Sorry, but I simply tried to provide as much information as possible...
yes, I appreciate that.
>> hm, comparing the files "Rebuild model/SceneImp_write.txt" and "Read
>> rebuild model/SceneImp_read_5.txt" (IIUC these are a dump of geometry
>> that looks correct in your app and a dump after saving and loading back
>> in, correct?) there are some strange changes in positions, often a 0.5
>> change in the Z-coordinate, but other (larger) differences as well.
>>
>> Since you have this Geometry dumping tool, together with diffs of the
>> resulting files it should be possible to make sure that the data is
>> correct up to the point it is written - that way we could exclude
>> problems in your app.
>>
> I will do.
>
>> Also, to reduce other effects, you could try using
>> OSG::OSBDriver::writeFC() to write just the Geometry when writing .osb
>> files.
>>
> Thats new to me. I will have a look.
it's only in there for a few months, somebody was asking about writing
not only Nodes to OSB so this interface was added.
>> I guess, they all seem to have a few triangles sticking out. I'm
>> assuming all along that is in fact the problem we are talking about in
>> this thread, right?
>>
> Yes, but I have a special memory manager running. My aim was to exclude
> problems in that direction.
hm, not sure, but then again this whole thing is kinda strange... ;)
>>> 2. Is the write1.osg file correct? Is there a problem with the write
>>> backend
>>> for this file type?
>> Which write1.osg is this? I have "Rebuild model/write1.osg" and "Read
>> write1.osg/write1.osg".
>>
> Ups, I was thinking about Rebuild model/write1.osg.
ok.
>> If you think there is something wrong with them,
>> please just mention what it is, that way I can much faster check if it's
>> really a problem ;)
>>
> You are right. I did read this file ('Rebuild model/write1.osg') with the
> '10loading.exe' example. I did have to insert some code before the osgInit
> call, namely
>
> OSG::preloadSharedObject("OSGFileIO");
> OSG::preloadSharedObject("OSGImageFileIO");
> OSG::preloadSharedObject("OSGContribDataSolid");
yeah, that is a windows problem. The linker is quite aggressive in
removing DLLs that appear unused. For the IO stuff the DLLs only
register themselves with a singleton in OSGSystem, therefore the linker
believes there is no use of any symbol in OSGFileIO and omits loading
it. It would be nice to have a better solution, but I don't know of any.
Of course, even if the problem is fixed for OSGFileIO, OSGImageFileIO,
the OpenSG examples are not linked against OSGContribDataSolid, so that
one needs to be loaded "by hand" anyway.
> to get it work. File reading always results in a root node with a null core
> and no rendering. However, ascii file inspection did not reveal a problem to
> my eyes. Unfortunately, I couldn't debug the file loading procedure due to
> the lex/yacc based parser code.
>
> I would like to know if the layout of 'Rebuild model/write1.osg' is correct
If I remove the GeoToEntityAttachment manually from the file (I did not
compile the ContribDataSolid lib, so it was choking on an unknown type)
I can load it with both testSimpleSceneManager and 10loading.
Interestingly enough it also does *not* show the sticking out triangles.
> and why I get this null core on loading this file with '10loading.exe'.
hm, sorry no idea, it does not happen for me, I just changed 10loading
like this to verify:
scene = OSG::SceneFileHandler::the()->read(argv[1]);
assert(scene != NULL);
assert(scene->getCore() != NULL);
> Interestingly, I could load this file with my application. As I tried to
> explain, I do not use the whole scene graph in my app, but only the tree
> branch starting at the '__StaticRoot__' named node. Hence, in this case the
> geomerty part is correct! (Not so on doing the same with one of the osb
> files).
yes, same here (i.e. the geometry is good), so it must be the OSB writer
or loader that mess things up, interesting. I'll see if I can find out
what is going on.
Cheers,
Carsten
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
