Hello Carsten, "Carsten Neumann" <carsten_neum...@gmx.net> schrieb im Newsbeitrag news:4c45d42c.60...@gmx.net... > > is mod4.osb from the first time saving or is it from loading and saving > again? > I think that the mod4.osb file is not the best one to analyze the problem. I have therefore tried to produce some better files.
For the following I have uploaded all files to 'files.zip' on http://drop.io/OpenSG_RenderEngine What I have done is the following: First I have loaded the original model file from folder 'Read original mode' with the cryptic name '0A09AFC5-BD4F-4C65-9416-DDFD4003986B.osb'. This scene is rendered incorrectly. In file 'SceneImp.cpp' you can see the 'SceneImp::Read' function which is peppered with debug code. The following files are produced in this function be reading the original model: Folder 'Read original model': opensg.txt - OpenSG logging. I have added a dumb call to the loaded scene (internalRoot node). SceneImp_read_0.txt - I have explicitely written the relevant geometry core data read_10.osg - Subsequent writing of the just loaded scene to format opensg ascii 'osg' read_20.osb - Subsequent writing of the just loaded scene to format opensg uncompressed binary 'osb' read_30.osb - Subsequent writing of the just loaded scene to format opensg compressed binary 'osb' Next I have refacet my model which results in a newly build scene graph branch and saved it by function 'SceneImp::Save' to the internal file 'AC9D1BE6-63E8-4E51-B972-4EF1F9121BCF.osb' found in folder 'Read rebuild model'. At this time the rendering of the model is correct in my application. Additional, I have written the very same scene to the different opensg formats and also provided the details on geometry core setup. The following files are involved: Folder 'Rebuild model': builder.txt - the geometry core details generated by the ctor in file MergeGeomBuilder.cpp SceneImp_write.txt - the same data but written just before saving, i.e. nothing happend inbetween write1.osg - the refacetted model in format 'osg' write2.osb - the refacetted model in uncomressed 'osb' write3.osb - the refacetted model in compressed 'osb' Now, I have read the just created model 'AC9D1BE6-63E8-4E51-B972-4EF1F9121BCF.osb' and produced the same information as in reading the original model. The rendering is incorrect this time. I have to explain one important detail of the file loading process in my application. I do not load a scene and replace the scene manager's internal root node by this scene. Instead I load the scene and than search for all nodes with a special name attachment (static root). These nodes get then be added to the scene manager. The reason for that is that my application defines the lighing and view setup. i.e. the scene manager. In order to provide consitency, I have to replace clip plane chunks and the light model chunk as well as the ContainerCollection attachment of the static root node (see SceneImp::Read). This might sound complicated and complex but is in use since the very beginning of our OpenSG route. Folder 'Read rebuild model': AC9D1BE6-63E8-4E51-B972-4EF1F9121BCF.osb - the correctly expected model just saved opensg.txt - OpenSG logging. I have added a dumb call to the loaded scene (internalRoot node). SceneImp_read_5.txt - I have explicitely written the relevant geometry core data read_15.osg - Subsequent writing of the just loaded scene to format opensg ascii 'osg' read_25.osb - Subsequent writing of the just loaded scene to format opensg uncompressed binary 'osb' read_35.osb - Subsequent writing of the just loaded scene to format opensg compressed binary 'osb' Then I have read file write1.osg, write2.osb and write3.osg. The results for file wite2.osb and write3.osb are basically identical as for reading the refacet model 'AC9D1BE6-63E8-4E51-B972-4EF1F9121BCF.osb' and the rendering is as wrong as in this case. However, interesting are the results of reading file write1.osg. At first the rendering is correct after reading this file but I'm unable to write the loaded scene. I have no idea what is happening here, but I will further investigate. Folder 'Read write1.osg' opensg.txt - OpenSG logging. I have added a dumb call to the loaded scene (internalRoot node). SceneImp_read_1.txt - Empty since I did not found a geometry core in the scene by the find_geom_cores (1) call. read_15.osg - Corrupt. Subsequent writing of the just loaded scene to format opensg ascii 'osg' read_25.osb - Corrupt .Subsequent writing of the just loaded scene to format opensg uncompressed binary 'osb' read_35.osb - Corrupt. Subsequent writing of the just loaded scene to format opensg compressed binary 'osb' Additional, I have added the 'OpenSG' files specific to my application to folder 'OpenSG'. But there is nothing fancy found there. Sorry for the long mail but I think that something is not correct either in my code or in the OpenSG core. Currently, I have not found the place I have to dig further. Any help is very much appreciated. If it helps I can also provide more of the source code of my OpenSG based RenderEngine. As a first step it would help to know the following: 1. Does the rendering of the provided 'osb' files look correctly in a foreign OpenSG setup? I think that all necessary information (clip plane chunks, beacons,...) are part of the models. If not I have to add some more information into my model. But currently I'm fine with my model layout. 2. Is the write1.osg file correct? Is there a problem with the write backend for this file type? Best, Johannes (1) class find_geom_cores_helper { public: explicit find_geom_cores_helper(VecGeomsT& vecGeoms) : _vecGeoms(vecGeoms) {} osg::Action::ResultE enter(osg::Node* node) { using namespace osg; Geometry* geomCore = dynamic_cast<Geometry*>(node->getCore()); if (geomCore) _vecGeoms.push_back(geomCore); return Action::Continue; } private: VecGeomsT& _vecGeoms; }; void find_geom_cores(osg::Node* node, VecGeomsT& vecGeoms) { using namespace osg; find_geom_cores_helper helper(vecGeoms); traverse(node, boost::bind(&find_geom_cores_helper::enter, &helper, _1)); } ------------------------------------------------------------------------------ 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
