Created obj + mtl loader

[mandrav]

(click here for full size)

That's better!

Seems CuteAlien was right: it needs mirroring on the X axis and then flipping the normals.

@hybrid: I 'll send you a new patch about this.

EDIT: patch sent.

[vermeer]

Seems CuteAlien was right: it needs mirroring on the X axis and then flipping the normals.

And me too. :p

btw, is usual with exporters, converter, loaders, 3d packages, engines...that x , y or z do change orientation.

Nope.

Yep. :p

[mandrav]

Seems CuteAlien was right: it needs mirroring on the X axis and then flipping the normals.

And me too. :p

Sorry not to credit you. I must have missed it...

Nope.

Yep. :p

If you mean the normals issue, then "Nope"
The mesh was imported wrong by this loader, not the normals. *After* I fixed the importing of the mesh, then it was a "Yep", the normals needed flipping

[vermeer]

oh, well, I mean, seing it all black can only be normals inverted (flipped, however the term..) or... some more rare problem, the face order changed. But is usually flip normals. Otehr times, depending on the engine or viewer, is thelack of a texture. That in some game engines put all stuff as black or white ambient at 100%.

the credit thing was ironical..

about the axe thing, to put you an example, many x exporters need a flip of x or z, or y axes... i find it so much times, that I almost expect it.. with workflows that go from one program to another and end up in a game engine.

[hybrid]

Ok, I changed the code accordingly. However I did it somewhat before, directly when reading the values. This saves some conversions! I have also found that the texture coordinates were really strangely handled. For me, the current patch is not working, but I have just one textured .obj file which may be buggy. So we definitely need some more testing! Or a definitive source telling about the coordinate system used.

[loonychewy]

I've updated my original code with the patches from hybrid's website, which should contain all the patches submitted so far. This should be useful for those who don't use patches. Can get them from my first post.

I've also added an end of buffer check at line 634 of CObjMeshFileLoader.cpp to prevent a buffer error.

As for some of the discussions thus far, I'll add in my half cents. I'm no expert on .obj meshes (and 3D graphics in general). I've not managed to find much info on the coordinate system too. My main sources of references are http://pipin.tmd.ns.ac.yu/extra/filefor ... j_spec.pdf, http://www.fileformat.info/format/material/ and Nate Robins OpenGL tutors. The latter has an OpenGL loader implementation and some obj models that I use for testing.

Also, it appears to me that the inversion of the colours is not correct for those models, as compared to when I load them in Maya. The uninverted colours is correct in my case.

[CuteAlien]

Hm, looks like i wrote this long article here and forgot to press "submit" :(. Ok, once more:

In readMTL we should not expect 'N' to be 'Ns', as some .obj files also contain 'Ni'. So i'd change it like that:

Code: Select all

        case 'N':
			if ( 0 != pCurrMaterial )
			{
			    switch(pBufPtr[1])
			    {
			        case 's': // Ns - shininess
			        {
                        const s32 COLOR_BUFFER_LENGTH = 16;
                        c8 nsStr[COLOR_BUFFER_LENGTH];

                        pBufPtr = goAndCopyNextWord(nsStr, pBufPtr, COLOR_BUFFER_LENGTH, pBufEnd);
                        f32 shininessValue = core::fast_atof(nsStr);

                        // wavefront shininess is from [0, 1000], so scale for OpenGL
                        shininessValue *= 0.128;
                        pCurrMaterial->material.Shininess = shininessValue;
                        break;
			        }
			    }
			}

			pBufPtr = goNextLine(pBufPtr, pBufEnd);
            break;

As for the inversed colors, i think this could be related to the illumination parameter which is not yet used. I've only got some .obj here and they are all set to illum = 4. In those obj's nearly all Kd values are set to 0 and all Ka except those where the graphican has set them explicitly to another value are also 0. By inverting the colors those images look certainly a lot brighter, but i don't think it's correct. I guess the way those values are used are at least partly defined by the illum mode. So far i thought ambience is calculated always the same way, but if the descriptions of my graphican are correct, then Maya seems not just to multiply for example material.ambience*light.ambience. He said in Maya faces can be brightened up with ambience light even if the material.ambience is 0.

[imagination304]

Hi all,

Could this tool be used for poser .obj?

Thanks in advance
Sammy

[CuteAlien]

Hi all,
Could this tool be used for poser .obj?
Thanks in advance
Sammy

Sorry Sammy, i think you will have to try it out. Mostly the .obj format which different programs export looks similar, but there a minor differences so there can be problems sometimes.


Hm - i just found another bug when trying to merge this patch with the svn version.
The SObjMtl copy-constructor should look like that:

Code: Select all

SObjMtl(const SObjMtl& o) : material(o.material), name(o.name), illumination(o.illumination) {}

[alc]

I just downloaded and install the patch from hybrids webpage. It compiles nicely, but didn't load the OBJ file; it reports "unknown format". It seems that patch did not update CSceneManager.cpp to include the OBJ loader as a default loader. Perhaps this is caused by the way I used the patch? I'm using Win32 and the patch.exe tool. The other cpp and h files were updated correctly, thought. When I included the OBJ loader in the default list, it loaded the model.

However, I have a sunflower model and a tree model that I use for testing, and both had semi-transparent textures after loading (it is leaf textures, so they are not suppossed to be transparent, except in the alpha channel, which they are). So, I also changed the MaterialType in the 'm' case, type == 2 of the MTL loader from EMT_TRANSPARENT_ADD_COLOR to EMT_TRANSPARENT_ALPHA_CHANNEL_REF. The latter could be without _REF, but this works fine and is somewhat faster according to the API doc.

Then the texture for the tree was ok (two textures in two files), but the texture for the sunflower was not (four textures in each corner of one png file). Visually, I could tell that the sunflower four-in-one texture should be upside down, and flipping it produced the right result. When I changed the PNG file to a BMP file it needed flipping left/right as well to be correct. Weird!

I noticed a minus in the TCoord assignment in the OBJ loader. When I changed this to plus, the sunflower (using the PNG) was correct, but now the tree was wrong ... *sigh*.

Anyways, this is not a problem (in the sense that I have the result I want). Just a comment in the eternal quest for more knowledge.

[hybrid]

you should carefully read instructions. Then you would have seen that you have to update CSceneManager on your own. This is because the many new loaders are interfering with each other and make it always necessary to fix the scene manager manually.
The transparency thing has to be looked into some more. I think I had my .obj files loading it correctly, but maybe I did not check the textures properly. As soon as the patch is included in SVN I'll try to fix some of those issues mentioned in this thread.
The texture coords have been discussed already, and it's also likely that it's a problem of the image loaders which are often flipping the coords, or of a d3d/OpenGL problem.

[loonychewy]

Reading the new posts here suddenly triggers me to check the patches against the Irrlicht 1.0 source. There's a slight modification to CSceneManager.cpp in 1.0 that I've updated against. Have also retained the 0.14 version in case anybody still needs it.

May I also propose that we can try to share with each other any models that seems to load incorrectly, so that there's more pairs of eyes to look into it. This is of course provided that the models can be released.

[Shakira22]

really ?