Hi.
I am using exporter plugin for 3dsMax 2018, and when I export model to GLTF/GLB format UVs seem wrong.
Babylon format works fine.
Does gltf supports UV coordinates or am I doing something wrong? Or there is something wrong with exporter, maybe it’s some older version or something.
Summoning @Drigax
I tried the latest version CD Pre Release 20191016.5 and 3dsMax showed a bunch of errors on open, saying that’s something wrong with the files.
I tried with the CD Pre Release 20191016.3, I made it work. But results after exporting were the same as before. GLTF/GLB UV doesn’t show properly.
EDIT: Okay, I managed to make latest version to work. But export result is still the same.
Ok, can you share your scene and your export logs? There is a known issue in glTF where certain UV transformations aren’t fully supported, I wanted to rule this out before investigating deeply.
Thanks
When I export scene with option “Write textures” texture is properly applied. But I want to create material inside the code and apply it on meshes. When I export the scene with “write textures” on, and create material with the same diffuse texture, and overwrite the default one, it still doesn’t apply it properly. That’s weird because it’s the same material with the same texture, and it looks differently.
Both cases when I’ve noticed this behavior is when I imported fbx file into the 3dsMax and then exported the scene. I’ve tried creating test model inside 3ds max (without importing external files), and it works as it should, nothing is wrong.
Here are the the files you asked for
Hi @nogalo, I’ve been busy last week resolving a regression with the Maya exporters, sorry for the slow reply.
I’m not sure if I’m able to reproduce what you’re encountering. Using the latest exporter I can configure a physical material using Drawer Texture(Final).png as the base color texture and export:
Likewise if i export the scene to FBX, then reimport the scene into Max2020 and export I get a similar result:
You say that:
Can you help me understand how you create materials in code? If you can provide a BabylonJS PG that reproduces this process, it should help us root cause what’s going on.
Hi @Drigax.
I had same problem as @nogalo.
This happen when export model to glTF and try to set dynamic material to model by code.
So I tested on other platform(Blender and Cinema 4D).
It was easily solved when I chose one option in Blender and Cinema 4D.
The problem is this glTF exporter don’t have “without UV” option unlike the Blender and C4D.
or need texture.flipY = false this option like --no-flip-v on following link
Thanks.
I’m sorry, I don’t quite understand, can you add some examples or sample scenes that explain exactly what functionality you want? I can add a flag to the exporter that doesn’t invert our mesh UV coordinates at export, but I don’t fully understand why we would want this other than as a workaround for improper behavior.
I’m not expert so I don’t know exactly why but, I think exporter need --no-flip-v feature.
Converter basically flip-v because webGL texture uv offset is different…
However, these converted models are expressed differently in different libraries when apply material
(I used to use playcanvas.js).
This is 3ds max glTF converter so I think shoud be well represented in all libraries.
In order to do that, It need --no-flip-v feature.
Hey guys. To be honest, this is still issue for me. For a while now I am not using gltf/glb formats in my scenes for the reasons above. And I would like to use them as they support PBRMaterials and I can apply Draco compression easily, which would help a lot.
Basically the issue is the same. IF I export the model with the texture on it, that usually works properly. Texture is exported and applied on the mesh as intended. But if I change and apply new texture on the same mesh dynamically within the code, the UVs are completely off. I had that issue in many projects so far.
I think @Drigax has answered you about this some months ago:
Providing a PG would help I think.
https://www.babylonjs-playground.com/#YIU90M#163
So as I mentioned before, initially if I export a model in glb with the texture it looks okay. But if I try to use that same texture and apply it to the existing material, suddenly it looks wrong, like UVs are messed up.
You can see in the PG that it looks okay initially. Uncomment line 21 to assign new texture (same texture basically).
you can try to load the babylon version of this (uncomment line 11 and mat2), and you can see that it doesn’t have this issue. Is it PBR vs Standard issue?
I don’t know what is going on, but this happens everytime I use this approach, I basically cannot manipulate materials in my projects, which I often need to do, so I am going with .babylon format. But at the moment I have specific project which would benefit greatly with glb and PBRMaterials.
Thanks
It is the texture that is flipped vertically.
If you do:
var texture = new BABYLON.Texture("https://i.imgur.com/aitxVV3.png", scene,
true, false);
it does work.
The problem is not PBR but glTF: when loaded from a glTF file, the inverY flag of the texture constructor is set to false to comply with the spec. So you should do the same thing if you want to be compatible.
hey @nogalo
Check out this iteration:
https://www.babylonjs-playground.com/#YIU90M#167
The two objects that you are applying the same texture to do not have the same UVs. Babylon textures define 0,0 as the topleft of the image, WebGL and glTF deifne 0,0 as the bottom left of the image. Therefore, to be used between models authored in the two formats, the images need to be inverted. (the alternative to this is inverting the glTF model’s texture coordinates to the babylon UV format, which will dramatically slowdown load times)
When we want to use a texture directly imported into babylon, we interpret the texture data as inverted by default, in order to fit babylon’s directX like texture space schema.
As an experiment, let’s try to apply the texture from our gltf directly onto our babylon file:
https://www.babylonjs-playground.com/#YIU90M#168
Here’s an documentation page by @PatrickRyan that explains this disparity in depth:
https://doc.babylonjs.com/how_to/normal_maps
Taking the exported scene into blender also demonstrates that these can’t really be treated as equivalent assets:
Babylon Model:
glTF Model:
EDIT:
I would reccomend inverting the textures to be used on your glTF assets via cloning the texture (we use an internal datastructure to contain the actual texture buffers) this clone should just allow us another way to interpret the textures:
Thank you guys. This solved my problem. Actually few days ago I encountered this exact issue on different project. After some debugging, I figured out that I need to invert the textures (because they were obviously flipped on the model) I didn’t know why, I didn’t know why it was never the case before. But I did it and it worked.
This now completely explains it to me (that topleft/bottomleft thing was crucial, it is kinda obvious now that I know it -.-). This helps me a lot and enables me much better workflow for my project (in the case of this project, it wasn’t so obvious to me that textures are flipped, as mesh and baked textures are much more complex, so it kinda didn’t occur to me that I need to do this) And now I even know that my “accidental” implementation in one of the projects will not work for each case (as I am using different formats there).
Thanks again, I really appreciate it. All the best 
