[not supported]Issue with obj reader

[wing64]

Trunk Revision: 4320
File: COBJMeshFileLoader.cpp
Function: COBJMeshFileLoader::readTextures() after line: 336 add below code for go next word and program go to handle options loop

Code: Select all

io::path texname(textureNameBuf);
bufPtr = goAndCopyNextWord(textureNameBuf, bufPtr, WORD_BUFFER_LENGTH, bufEnd);

ps. line: 422 must remove

[CuteAlien]

@wing64: This looks wrong on first view. Because the idea is to get texname _without_ the parameters, so it's only copied once those are removed. So I think changing it like that would break stuff. But I guess you had some problem with this or you wouldn't mention it. Please give us the corresponding line in your .mtl file which goes wrong then we can check what the problem is.

[hybrid]

Please also note that .obj and .mtl is not very good specified. So many exporters do their own stuff, so we might have to integrate more than one solution, as long as we can distinguish those situations.

[wing64]

Code: Select all

newmtl lambert2SG
illum 4
Kd 0.00 0.00 0.00
Ka 0.00 0.00 0.00
Tf 1.00 1.00 1.00
map_Kd UV01_bg2.jpg
bump UV01_bg2_NRM.jpg -bm 0.2066
Ni 1.00
 

after read UV01_bg2_NRM.jpg then program not read parameter -bm 0.2066

[CuteAlien]

I see... the problem is likely that the -bm parameter is given after the filename, while it's usually before it. I guess we can rewrite that and make parameter reading position independent. Out of curiousity - which tool does export it like that?

edit: Hm, not even so trivial making this position independent, as "-bm 0.2066.jpg" would be a valid filename for example. But I guess I can search again for a filename if it hasn't found one at the end.
edit2: Then again I just realize "-bm 0.2066.jpg" would probably always fail anyway :-)

[christianclavet]

Is the "bump" parameter is mapped directly by Irrlicht? Exporting a model with a bump map will display in the model viewer without changing the material type?
If this is possible, is that a bump map (greyscale) or a normal map and what material type Irrlicht will switch to?

[CuteAlien]

Hm, have to read obj loader to find answers to those. If I'll ever find out I tell you :-) I'm by the way still working on this bug - when I started fixing it I realized there's a bunch of further parameters which is ignored right now and that had stopped me from doing a quick fix. But will fix this soon - as soon as I'll get back to find some time for Irrlicht (wasn't much the case the last weeks).

[robmar]

I´ve been testing with an MTL produced by DEEP Exploration 3.5.10.1242, and the bump names do have preceeding digits:-

newmtl tile
Ka 0 0 0
Kd 0.72549 0.428165 0.187774
Ks 0.217647 0.128449 0.0563322
illum 2
Ns 8
map_bump 20_metl010b.jpg
bump 20_metl010b.jpg <---------- duplicated in MTL, so only first must be processed, Robmar

The newTexture flag in the obj loader is handled incorrectly, so I´ve changed this to a member flag bTextureDone, which gets cleared on each new material, and set when the first bump_map or bump line is normal´d, preventing repeats.

[CuteAlien]

Another very old thing... I've looked on this a few times over the years without knowing what to do with it.
svn trunk [r6602] (Irrlicht 1.9) has now some changes related to this:

The bump textures in robmars example which start with a number were messed up in Irrlicht as the number was assumed to be a scaling parameter. Unless some exporter actually does that, but that would be strange and would have still been handled wrong as then Irrlicht assumed another filename to follow. So that got fixed.

The -bm at the end of the line is just wrong and I'm not going to fix that. Options have to be before the filename and exporters not doing that are messing up.