Texture support for PLY format

[acy]

I am trying to add texture support to PLY loader by copying relevant parts of the OBJ loader.

https://github.com/acyildirimer/irrlich ... leLoader.h
https://github.com/acyildirimer/irrlich ... Loader.cpp

After adding texture to material of the model it become completely black. Same thing happens in 09.Meshviewer example if I open a PLY file and a texture file after that.

Tried different lighting settings but result is the same.

[CuteAlien]

Check what happens if you manually set the textures after loading (like for example: node->getMaterial(0).setTexture(0, texture)).
If you see textures then the bug is in the loader. If it's still black it's in the lighting.
You said different settings - but didn't mention what you really tried. First one should be to disable lighting in the material (then lights no longer matter).

[acy]

I've tried to set texture manually but it is still the same.

//with light source
smgr->addLightSceneNode(0, vector3df(200, 200, 200), SColorf(1.0f, 1.0f, 1.0f), 2000, ID_IsNotPickable);
smgr->setAmbientLight(SColorf(0.3f, 0.3f, 0.3f, 1.0f));
model->setMaterialFlag(EMF_LIGHTING, true);

//without light source
model->setMaterialFlag(EMF_LIGHTING, false);

[CuteAlien]

Sounds like your vertex-colors are set to black.
Try if doing something like this changes it: SceneManager->getMeshManipulator()->setVertexColors(model->getMesh(), irr::video::SColor(255,255,255,255));

[acy]

Sounds like your vertex-colors are set to black.
Try if doing something like this changes it: SceneManager->getMeshManipulator()->setVertexColors(model->getMesh(), irr::video::SColor(255,255,255,255));

Still the same. It is reproducible in 09.Meshviewer example if anyone interested.
File -> Open Model File & Texture... > Select PLY model
File -> Open Model File & Texture... > Select texture file

PLY model and texture : https://artec3d-production.s3-eu-west-1 ... ir-ply.zip

[CuteAlien]

The ply-model has no uv-coordinates, so they all show a single pixel in the texture (in your case accidentally black, with other textures you get other colors).

edit: Although it is not the problem in this model, I should probably note that the ply-loader in Irrlicht 1.8 had a problem with loading uv-coordinates which were marked as 's' and 't'. It's not really defined well in this format so some tools use that instead of 'u' and 'v' for uv-coordinates. This is only fixed Irrlicht svn trunk which can now load both.

[acy]

The ply-model has no uv-coordinates, so they all show a single pixel in the texture (in your case accidentally black, with other textures you get other colors).

Sorry, I should have sent one of the files I am working with. I think this one includes uv coordinates : https://github.com/acyildirimer/irrlich ... /model.zip (Both meshlab and irrlicht with assimp loader draws texture correctly). I will look into assimp sources and hopefully I will find what is missing.

edit: Although it is not the problem in this model, I should probably note that the ply-loader in Irrlicht 1.8 had a problem with loading uv-coordinates which were marked as 's' and 't'. It's not really defined well in this format so some tools use that instead of 'u' and 'v' for uv-coordinates. This is only fixed Irrlicht svn trunk which can now load both.

I am using trunk version.

[CuteAlien]

OK, fixed it in svn trunk r6133.
Seems there is yet another ply format out there - this one using texture_u/texture_v for uv coordinates.
Out of curiosity - do you know which tool created that one?
Bit strange that each tool seem to prefer to use a different label for it :-)

[acy]

OK, fixed it in svn trunk r6133.

Thanks a lot.

Seems there is yet another ply format out there - this one using texture_u/texture_v for uv coordinates.

Somehow I never suspected parser. I thought those keywords were strictly defined. Sorry for the trouble.

Out of curiosity - do you know which tool created that one?
Bit strange that each tool seem to prefer to use a different label for it

I think it is called bellus3d.

[acy]

Only bottom part of the texture is being drawn on the model.

[CuteAlien]

Yeah, I noticed that. But the texture didn't have a complete face, so I thought maybe there's a second texture for upper part. Sorry, I'm on wrong system right now, so can't test right now, but my guess would be that it maybe is more than one meshbuffer, so textures for other meshbuffers have to be set?

[acy]

Rotating texture by 180 degrees solved the problem.

Edit : Flipping the texture vertically instead of rotating.

[acy]

I think it is related to opengl driver. Setting texture matrix of the material like the code below when using opengl driver fixes the problem.

core::matrix4 textureMatrix(1, 0, 0, 0, 0, -1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1);
mb->Material.setTextureMatrix(0, textureMatrix);

[CuteAlien]

It seems the ply format doesn't really define stuff like that. It's a very flexible format which allows passing a lot of custom information (which Irrlicht ignores). Irrlicht just parses some common files basically. So this format really only works if you know the tool which created the file and then interpret the values that tool used afterward correct.

In your case a better solution is usually to flip uv's (maybe only x or y) for the mesh after loading.

It might be possible to improve the loader if tools write for example additional information (like which tool made the file) into the comments.

[acy]

Meshlab and assimp loaders works without any definition related to it. Is it because coordinates in the PLY file generated for right-hand coordinate system and those tools uses right-hand coordinate system by default? Some of the PLY files have "comment CoordinateSpace RIGHT_Y_UP" line which is most likely means right-hand coordinate system.

In your case a better solution is usually to flip uv's (maybe only x or y) for the mesh after loading.

What is the correct way to do it? Mesh coordinates * world matrix or swapping axes in the PLY loader?

Thanks.