Created obj + mtl loader

hybrid · Post by **hybrid** » Tue Apr 11, 2006 5:28 pm

No, this default value for alpha is not inversed, so apparently the inversion is wrong. I'll have to check my models then. I will update the patch tight away. the defaults are indeed missing, will add them soon.

hybrid · Post by **hybrid** » Tue Apr 11, 2006 11:37 pm

Ok, patch with default materials, and multi-materials per group is uploaded. You can now also have faces without groups or materials etc. And negative indices are supported.
I did not include your emissive settings - will have to experiment some more.

mandrav · Post by **mandrav** » Thu Apr 13, 2006 11:15 am

This OBJ+MTL loader has a major problem and I wonder why people haven't noticed it before...

I always keep my assets (models, sounds, etc) in a separate sub-directory, i.e.

Code: Select all

project_root
|
-my.exe
|
-my.cfg
|
--data
  |
  -mesh.obj
  |
  -mesh.mtl

With this configuration, when trying to load "data/mesh.obj", the material can't be loaded because it tries to load "mesh.mtl" and not "data/mesh.mtl" as it should. A crash follows.

Luckily, it was easy to fix that, at least for such simple cases.
@hybrid: if you want, tell me where to send this patch so that it is added in your patches page (great work there, btw

).

Yiannis.

hybrid · Post by **hybrid** » Thu Apr 13, 2006 11:32 am

You should find my e-mail adress at the bottom of the patch page.

mandrav · Post by **mandrav** » Thu Apr 13, 2006 11:38 am

hybrid wrote:You should find my e-mail adress at the bottom of the patch page.

Oh, THAT easy

Done.

hybrid · Post by **hybrid** » Thu Apr 13, 2006 12:44 pm

Ok, patch is included in the main patch. I have also changed some method signatures from c8* to const core::stringc& to avoid the many stringc constructions while searching for materials. Though no functional changes in my part.

CuteAlien · Post by **CuteAlien** » Thu Apr 13, 2006 1:24 pm

mandrav wrote: I always keep my assets (models, sounds, etc) in a separate sub-directory

Yeah, i didn't know how to include that in that patch. I solved that problem slightly different, by not exchanging the original .obj loader but including the new one in my project and adding it as external Meshloader. This way i could just add fuctions to COBJMeshFileLoader, like setTexturePath, setMaterialPath without the need to change the IMeshLoader Interface. But that was just a too ugly solution to post here ;-) New patch is not up yet (while writing this), so i don't know how it's solved now. I think the clean solution would be to add texture and material paths like it's been done for example with MY3D_TEXTURE_PATH.

hybrid · Post by **hybrid** » Thu Apr 13, 2006 1:41 pm

The new patch just replaces the old one. Maybe I should add a revision to the patches such that the changes becomre more visible. So simply remove the previous patch (patch -R ...), download the new one and apply it.

mandrav · Post by **mandrav** » Thu Apr 13, 2006 1:51 pm

CuteAlien wrote:
mandrav wrote: I always keep my assets (models, sounds, etc) in a separate sub-directory
Yeah, i didn't know how to include that in that patch. I solved that problem slightly different, by not exchanging the original .obj loader but including the new one in my project and adding it as external Meshloader. This way i could just add fuctions to COBJMeshFileLoader, like setTexturePath, setMaterialPath without the need to change the IMeshLoader Interface. But that was just a too ugly solution to post here New patch is not up yet (while writing this), so i don't know how it's solved now. I think the clean solution would be to add texture and material paths like it's been done for example with MY3D_TEXTURE_PATH.

I didn't do such an intrusive change.
What I did was, if the material library (or any texture in it) was not found, it tries a second time by prepending the relative path of the OBJ to the material library filename (and textures defined in it). Simple and effective.

CuteAlien · Post by **CuteAlien** » Thu Apr 13, 2006 2:15 pm

hybrid wrote:The new patch just replaces the old one. Maybe I should add a revision to the patches such that the changes becomre more visible. So simply remove the previous patch (patch -R ...), download the new one and apply it.

The link to the patch does not work currently, maybe a typo in the url?

hybrid · Post by **hybrid** » Thu Apr 13, 2006 2:18 pm

No, it just did not copy from my laptop to the server. Should be fixed now!

mandrav · Post by **mandrav** » Fri Apr 14, 2006 10:06 am

OK, there's definetely something wrong with this loader.
Here's a model I have created with blender and exported to obj.

This is how it looks in my own engine:

(click here for full size)

And this is how it looks in Irrlicht, using this loader:

(click here for full size)

As you can see, it's like mirrored and the textures are all wrong. Also, I have rotated the object in this view. Initially it would display the building's back side...

Let me note that this happens with every OBJ model I tested. Also of importance is that I use only OpenGL so this could be a coordinate system issue (quite probably).
Unfortunately, I haven't had the time to look into it just yet so I don't have a patch for it.

vermeer · Post by **vermeer** » Fri Apr 14, 2006 11:57 am

normals inverted?

hybrid · Post by **hybrid** » Fri Apr 14, 2006 12:02 pm

I just checked the format specifications found on the web and they don't say anything about the coordinate system used. Since Irrlicht uses the same coordinate system for all of its drivers there won't be a difference with DirectX. Maybe you can just try with some simple geometry if all axes are correctly translated.
The textures are also really strange. I had one model with textures applied and there the textures were not mirrored but partially offset. I will check whether there are any unsupported flags. Could also be a problem with coordinate system and mirrored texture offset or something. Also some textures are loaded flipped such that some simple texture problems could also be related to Irrlicht's Image Loaders. But there are more problems with this loader apparently.

mandrav · Post by **mandrav** » Fri Apr 14, 2006 12:12 pm

vermeer wrote:normals inverted?

Nope.

If you look closely, you 'll see that it's like flipped or something. Normally, the door should be at the left side, the chimney at the right.
This loader displays them at opposite sides...
This is the worrying part. The texture issues can be solved later, although if the vertices problems are fixed, the texture should show up nicely...