Hello Sebastian,
On 12/06/2010 09:26 AM, Sebastian Till wrote:
> I am still using OpenSG 1.8, wrote a small application to test background
> loading of images and noticed some strange things in the OBJSceneFileType
> while loading *.obj files.
>
> Each *.obj file I am using refers to a common material library where all
> important materials are stored. So the head of an *.obj file looks like that:
>
> -OBJ-FILE-BEGIN---------------------------
> mtllib ../materials/materials.mtl
>
> usemtl matX
>
> ...
> -OBJ-FILE-END-----------------------------
>
> Where matX refers to a material in the given material.mtl and where the dots
> mark the place for geometry definitions.
>
> If I define *.obj files this way, the current implementation of the
> OBJSceneFileType class will create every material in the mentioned material
> library for each *.obj file. So, for example, if I have four *.obj files,
> each with a different material, OpenSG will create 16 materials this way.
>
> To avoid that I changed the OpenSG 1.8 sources by making the variable mtlMap
> in OBJSceneFileType::read() static and by adding trivial checks for already
> existing materials to the method OBJSceneFileType::readMTL(). This didn't
> really fix the problem because my version also creates potentially
> unimportant materials since the material library contains all materials even
> those not used in a particular scene.
>
> Am I doing something wrong here or is this really a bug? I checked the OpenSG
> 2.0 sources, too. It seems that *.obj files are still being treated this way.
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.
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.
Cheers,
Carsten
------------------------------------------------------------------------------
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
