Three.js: ObjLoader + MtlLoader not displayed correctly (multimaterial in one MTL ?)

[Aikyos]

Hi,
I link to you my obj and my MTL i want to import in my code like this :

var mtlLoader = new THREE.MTLLoader();

mtlLoader.setPath('models/');

mtlLoader.load( 'citadine2.mtl', function( materials ) {

    materials.preload();

    var loader = new THREE.OBJLoader( manager );

    loader.setMaterials( materials );

    loader.setPath('models/');

    loader.load( 'citadine2.obj', function ( object ) {

        object.name="citadine2";

        scene.add( object );

    }, onProgress, onError );

});

But the best i can got it's that :

And what i want its this : I got this with import my both files to http://3dviewer.net/.

It seems Objloader can't have a mtl with multimaterials.

See my files :

models.zip

Can you tell me what i am doing wrong please ?

Thank you & sorry for my bad english.

Three.js version

• [X] Dev
• [X] r87
• [ ] ...

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [] All of them
• [x] Windows
• [ ] macOS
• [ ] Linux
• [ ] Android
• [ ] iOS

Hardware Requirements (graphics card, VR Device, ...)

[Mugen87]

I can confirm that both OBJLoader and OBJLoader2 display the model in a wrong way. As you can see in the screenshot, Sketchfab can handle the obj and mtl files correctly.

It seems Objloader can't have a mtl with multimaterials.

No, this should actually be supported.

\ping @kaisalmen

[kaisalmen]

OBJLoader2 with ambient lighting at 0xFFFFFF looks like this:

It seems to be an issue with double side or transparent materials. Need to find out if MTLLoader already creates materials with wrong properties. Will investigate....

[Aikyos]

Thank you guys.

[kaisalmen]

@Aikyos @Mugen87 with enforced two sided materials and VertexNormalHelpers active for the complete mesh you can see that the surface orientation of the windshield is not correct:

Only looking at mesh "VitreAV_Plane.043" without double side material enforced and VertexHelper in place you can see that the normal orientation is wrong:

Intermediate results:
Done:

• OBJLoader2 processes everything correct.
• http://3dviewer.net/ seems to enforce THREE.DoubleSide. This becomes obvious when you move the camera inside the car
• TODO: Test OBJLoader considering what is now known

[kaisalmen]

On the branch above I modified one obj and one obj2 example for demonstration purposes. The obj and mtl files are contained, but are not foreseen to be contained in a potential merge request.
I commented the missing maps in the mtl file, otherwise the materials look odd (potential MTLLoader improvement needed here?).
Example OBJLoader + MTLLoader makes all materials THREE.DoubleSide and it now uses TrackballControlls to ease navigation. Example OBJLoader2 usage options lets you switch the sie modes.

OBJLoader seems to have a problem with some meshes/materials as the bottom of the car is missing

OBJLoader2 seems to behave correctly.

Update 2017-11-12: Object vide_Plane.007 is the mesh not properly handled by OBJLoader. It is created as LineSegments instead of Mesh and it has a multi-material with six LineBasicMaterial. OBJLoader2 creates the same object as Mesh with six MeshPhongMaterial.

[kaisalmen]

I will continue to investigate. I just didn't have the time to work on it.

[Aikyos]

No problem, your help is welcome. Don't worry about the time.

[mrdoob]

@kaisalmen any luck?

[kaisalmen]

I almost forgot about it, but this is next on my list. All other issues and enhancements are done or PRs are under review.

[kaisalmen]

@mrdoob This is a nasty one and not easy to fix. OBJLoader assumes that f (and there are four sub-types), l and p don't intermix before new vertices/groups/objects are declared, but this is exactly happening, see lines 32864-32873 from citadine2.obj:

f 8896/8775/7361 8094/8777/7363 8093/9207/7525 8092/9205/7182
f 8094/8777/7363 8091/8778/7364 8918/9206/7524 8093/9207/7525
l 9003 9010
l 9004 9008
l 9006 9011
l 9007 9009
l 9008 9002
l 9009 9005
o BrakeLight_Plane.015
v 0.059668 1.137745 1.244512

The spec does not forbid it, so it can occur and it does. I just made OBJLoader2 resilient to it lately and that is what the open PR mostly about. I wasn't aware until now though that it is exactly the same issue here. A recent bugfix repaired line rendering in ObjLoader. It applies the complete Line material to all read faces and lines as it does not start a new mesh internally:

It is the same reason why the verify from #13156 looks like this (top is OBJLoader2, bottom is OBJLoader):

The three missing cubes are described with different face-types.

The fix for OBJLoader2 took a couple of hours and that code I know better. For OBJLoader it is likely more complicated as we need to rethink the way meshes are detected.

[mrdoob]

Oh man, that sounds like a nightmare... Glad to hear that #13156 fixes this.
Thanks for doing all the investigation and for the verify file. Super helpful!

[kaisalmen]

OBJLoader2 stores which face type is active (all four f types, l and p) and creates a new mesh every time the face type changes in the OBJ file or in case g is declared. But, if for example the same f type is interrupted by v definitions used again only a new mesh is created when a new g is declared.

[mrdoob]

As far as I understand OBJLoader2 should be able to load this file correctly. Closing...