I added a default C4D cube there - https://playground.babylonjs.com/#YIU90M#576
All cubes are different now 
(while C4D default cube is OK at https://playground.babylonjs.com/#9AF7JS#1 )
Here we go, (again, uploading cube_mat.glb to sandbox seems to work correctly, but not in PG if material is aplied):
PG with Blender Cube having Texture
I noticed that sometimes in Safari the cube is black, like Blender, if the texture is transparent .png, but in Chrome, it’s white:
Unfortunately, no, because I need the same texture to be reused across all meshes, regardless where it comes from (Babylon, Blender, C4D…), to avoid code complexity, bugs and most importantly, to reach the performance target of thousands/millions of meshes rendering at 60FPS on a regular laptop.
The app allows users to customize Materials on the fly: combine different textures, rotate/scale/offset texture, and maps all Textures in close to life size scale dynamically (i.e. a cube of size 4, will have x4 more texture repeats than a cube of size 1).
2 Likes
But doesn’t setting vScale to -1 fix the issue of the inverted v coordinates, like in the second PG that I posted above using your mesh?
It solves .glb import and introduces bug to Babylon native meshes, because I cannot invert Texture, for reasons explained.
Maybe @PirateJC can help from a blender perspective
From Blender perspective you just have to mirror UVs on the original flipped-uv mesh, but if I well understand ecoin doesn’t want any operations from user on a DCC tool.
2 Likes
This is fully expected as you need to not inverse textures in this case to fit with the uv layouts of gltf files which are meant to not load inverted for perf purposes while uploading to the gpu: https://playground.babylonjs.com/#YIU90M#579 This is actually how the gltf loader itself is creating the texture.
Why would this not be the right approach in your setup ? (export from blender in gltf, load new texture uninverted)
Yes, correct - I cannot force users to do something non-standard on Blender or any tools.
Applying Material to imported Mesh inside Babylon should work the same way as if the Mesh was imported along with Material from .glb.
Otherwise, if I revert the imported mesh’s UV to work with Babylon Material, then the material that comes with the mesh in glb file becomes incorrect. And vice versa.
The ability to use both Babylon Material and embedded Material in glb file allows user to upload custom Models, like a Microwave with embedded Bosch logo texture, while allowing user to change color, or change from matte to glass finish inside the app.
In this scenario, imported Mesh will have Material combining Texture from imported file, and dynamic Texture generated by the app.
My bad, I forgot to reset the Texture to uninverted (the inverted code was left over from discussion with @labris earlier).
Nonetheless, the bug is still the same:
https://playground.babylonjs.com/#YIU90M#580
In the app, I do not invert anything, Texture is created using defaults.
Ps. I do not expect to introduce breaking changes to Babylon.js, just if someone to could point me to the code where this conversion happens, that should be enough.
However, this current behavior is clearly a bug to me, because I cannot combine Babylon Texture with embedded .glb Texture without some sort of adhoc logic, and suffering performance. I might have to completely rewrite the VertexBuffer.UVKind for imported mesh.
With this PG - https://playground.babylonjs.com/#YIU90M#576 - which shows 3 different results I think that it also depends on 3D editor default settings.
You should not invert texture in the app, this is the main point, if you target gltf, textures should not be inverted when loading: https://playground.babylonjs.com/#YIU90M#581
Exactly, but isn’t the purpose of GLTF file was to have standardized 3D models and structure?
Is UV mapping, right/left-handed orientation, etc. info somewhere embedded inside .glb so that Babylon can extract them and do proper conversions?
Provided:
mesh.glb has the same structure (regardless of tools used to export)
Expected
Mesh to look the same in Babylon
But then the Native Babylon Cube has texture inverted with :
new BABYLON.Texture(`${gitHubURL}texture.png`, scene, false, true) // `false, true` causes reverted texture on babylon Cube
Which is also expected, the only way to map them all is to also put the babylon cube in RHS.
You could also provide your own procedural meshes or swap UVs of default meshes if you want to stay in LHS or export default meshes from Blender in GLTF as well ?
Is your app meant to allow a mix of Babylon and GLTF formats ?
I added the swap function in https://playground.babylonjs.com/#YIU90M#582
2 Likes
Yes, user created meshes inside the app (wall, stairs, geometric shapes, like polygon, ribbon, sphere, etc.) are built with Babylon.
The catalog of items is built by uploading GLTF mesh files, combining them with Babylon meshes, to create truly unlimited variations with unlimited Material/texture combinations.
You are supposed to be able to build anything imaginable in 3D world, and create an entire 3D e-commerce store without CG skills), like this primitive demo:
Cool so the UV flip solution on my previous answer should definitely work if you do not want to switch your scene to RHS
2 Likes
Awesome, was it just changing one parameter from true to false? I cannot believe the fix is so simple, and we all walked around it for so long! 
Thanks alot!
Damn, I see below the code, you actually changed UV for native Babylon cube, so that’s VertexBuffer.UVKind reset approach, unfortunately for me, it’s not as easy to update on all other babylon meshes that are not cube, it’s a lot more complex than 1 - x logic.
It’ will be days of work to remap all UV logic for Babylon meshes.