The exporter doesn’t support multimaterial and thus this doesn’t work properly. Feel free to file a feature request on GitHub.
This is somewhat expected. This scene uses StandardMaterial. glTF uses PBRMaterial. There is no correct way to translate the behavior of StandardMaterial with a partially transparent diffuse texture to PBRMaterial as the alpha channel of the albedoTexture for PBR is intended for alpha as coverage. I suggest using PBR materials in this scene if you want them to translate well.
You can tell the exporter what to export by setting the shouldExportNode callback on the exporter options. Maybe we can automatically add one for excluding the disabled meshes for the inspector export button?
Is there an option to convert transforms correctly to Right handed system while keeping the default LHS in Babylon? (GLTF uses right handed).
Rotation is messed up and I cannot manually rotate the entire scene by Math.PI like the hack used in Babylon sandbox, because in the scene I have meshes transformed and nested multiple levels (i.e. rotated within rotation…)
I don’t know what you mean by this. The exporter converts the scene to RHS for glTF if the scene is in LHS. The loader converts the glTF to LHS using a root mesh if the scene is in LHS.
in PG, open Inspector and click Scene Export → Export to GLB
Open Blender New project, Import → glTF 2.0
Upon further investigation, it seems that relative rotations of nested Mesh/Nodes are preserved, only the top level Node (in PG, it is called root) is not rotated correctly. Camera and Light also have incorrect rotation, so I guess for the purpose of using Blender Cycles to take snapshot should not be a problem.
However, even using PBR material does not produce consistent result for Textures with transparent areas (turned back) - or is it a setting in Blender that needs to change?
Or it could be something wrong with the texture.png file itself, because when I tested with another PNG file, it had black area in both Babylon and Blender.
Please make the repro simpler. Having Blender in the equation is much more complex than it needs to be. This problem will reproduce just by reimporting the exported glb into Babylon.js sandbox. There are also too many objects in this scene for the repro. Please make it as simple as possible to repro.
The albedo texture has an alpha channel that should be ignored by the rendering engine whether Babylon, Blender, or anything else because that’s what the spec says for glTF. Babylon doesn’t muck with the albedo texture when exporting. My guess is that Blender is interpreting the texture incorrectly.
Before I take a look at this issue, did you try to import the .GLB in another DCC like Maya, 3DSMax or any other gltf viewer?
I just want to be sure the issue is not on Blender side.
I do not have Maya or 3DSMax to test, but I get the same black in babylon sandbox when imported back. The bug only appears on that particular png file, some other png I tested look black everywhere.
It must be a bug with Babylon itself, because both in PG and in my local setup, and production build, the texture appears white on both Babylon built meshes and imported GLTF meshes.
Here is a test I did with exported glb from the PG and loaded into https://gltf-viewer.donmccurdy.com/ that’s using ThreeJS which is right handed.
Big Box is at (0,0,0), sphere at z = 2 and small box at x = 2
As I can see it, the rendering is consistent between Babylon and Three. Grid axis sign is flipped when going from LH to RH. For me, it’s an issue with Blender…or did I miss something?
I believe, based on your screenshot, the LHS in Three has X azis reversed.
Three.js is irrelevant here anyway, because I need Babylon export to work with Blender for rendering with Cycles. And this bug is not from Blender side.
Perhaps someone here with a professional 3D software like 3DMax, Cinema4D, etc. can give us an exported GLTF file to test with (along with screenshot on how it looks like in their software) so I can compare it against Blender.