On 12/06/2010 10:48 AM, Sebastian Till wrote:
from your description there are two things going on here:
1) all materials (even the unused ones) from a .mtl file are created.
This is clearly wasteful and I'll be more than happy to accept patches
that only create actually used materials. That being said the unused
materials should get deleted after the loading completes, because
nothing references them any more - if they stay around that's a bug.
Well, then it's actually a bug (at least in OpenSG 1.8) but I can't
supply a patch. I just wanted to inform you about this issue. My small
changes were for testing purposes only and won't really fix the problem.
Nevertheless I can supply these changes if you are interested in them.
attached is a patch that should ensure that unused materials are
correctly deleted when the loader is done with a file.
It is only lightly tested, so if you give it a try I'd appreciate
feedback if it works for you. Thanks!
2) there is no sharing of materials across multiple file loads.
This is admittedly also not optimal, but OpenSG does not implement a
resource system that keeps track of loaded textures, meshes, etc. So
there really is not a good way for the system to locate already
existing materials (there is no central registry to ask). In 2.0 the
loader interface has a "resolver" argument, that can be used by
applications to implement caching, but currently only the VRML loader
makes some use of it.
I see. Thank you for your fast answers.
actually I think I was a bit too fast, I had wanted to mention that
there is the MaterialMerge GraphOp that at least should be able to
reduce the number of materials used for rendering (so you don't have to
pay for unnecessary state changes and waste texture memory). It attempts
to find identical materials and keeps only a single copy, replacing
duplicates.
Cheers,
Carsten
Index: Source/System/FileIO/OBJ/OSGOBJSceneFileType.cpp
===================================================================
RCS file:
/cvsroot/opensg/OpenSG/Source/System/FileIO/OBJ/OSGOBJSceneFileType.cpp,v
retrieving revision 1.33
diff -u -r1.33 OSGOBJSceneFileType.cpp
--- Source/System/FileIO/OBJ/OSGOBJSceneFileType.cpp 13 Mar 2009 11:41:01
-0000 1.33
+++ Source/System/FileIO/OBJ/OSGOBJSceneFileType.cpp 6 Dec 2010 22:59:42
-0000
@@ -544,6 +544,16 @@
}
}
+ std::map<std::string, SimpleTexturedMaterialPtr>::iterator mIt =
mtlMap.begin();
+ std::map<std::string, SimpleTexturedMaterialPtr>::iterator mEnd =
mtlMap.end ();
+
+ for(; mIt != mEnd; ++mIt)
+ {
+ subRefCP((*mIt).second);
+ }
+
+ mtlMap.clear();
+
SceneFileHandler::the().updateReadProgress(100);
return rootPtr;
}
@@ -871,6 +881,7 @@
if (mtlPtr != NullFC)
endEditCP(mtlPtr);
mtlPtr = SimpleTexturedMaterial::create();
+ addRefCP(mtlPtr);
OSG::setName(mtlPtr, elem.c_str());
beginEditCP(mtlPtr);
mtlPtr->setColorMaterial(GL_NONE);
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
