Hi all - I’ve found a bug that was introduced in 4.1.0 and persists in 4.2 alpha. When merging meshes the normals of the produced multimaterials appear wrong. I’ve created a Playground to demonstrate the problem. You can recreate it by switching between v4.0.3 where it works and a later version. You can see the effect on the windows and tables in the scene
https://playground.babylonjs.com/#7VTDIR
any ideas on a fix, or is it a genuine bug?
Thanks, taking a look now.
This is starting to look like a bug, as @loadpixels observes, it appears our meshes with multimaterials have normals inverted:
Looking at a minimized scene, we can see the vertex normals are all as expected, but the objects are being rendered as if they have the wrong side orientation?
This appears to uniquely happen to merged meshes composed of multiple materials…
I’ll start to look into change history for this codepath to see if there’s anything suspicious…
Looking at the data: nothing appears to have changed regarding how the mesh data is merged. Mesh vertices, normals, sideorientation, and facial indices appears unchanged:
See some debugging info for both babylon versions:
latest (4.2.0-alpha):
And both versions appear to export the scene without issue, further giving me the impression that the data is fine, perhaps we have a bug in our rendering code for some case of multimaterials…
@sebavan, how would one go about confirming this suspicion?
You could use spector to check if the inputs for the shaders are the same proving out a change in material. Let me know if you struggle with it 
Speaking of Spector, is there any way to get the values of an attribute buffer (or any buffer for that matter), or at least the first few values? That would be an hint to know if the buffers are ok or not (full of 0 for eg).
nope 
cause ppl wanted to use it to much to still models so we limited those capabilities for now
Maybe grabbing only the first 16 bytes or so of each buffer?
I often wonder if my shader does not work because of the code or because my inputs are bad. For simple types like float or vec2/3/4 it’s easy to know because Spector does display the values, but for a buffer it’s currently a black box. With only the first few bytes, it would generally be enough to know because 99 times out of 100, if your buffer is bad it is full of 0.
true I ll see if it would be easy to add.
Thanks for the insight! I think I’m starting to narrow down on a lead, I diffed spector’s parameter panel and found the only significant difference between the parameters was the front face mode set on the webgl context:
This appears to be set by the effective material, I’m now setting up a repo pointed to 4.0.3 to trace through where we’re initializing this winding order after merging materials…
Finaly figured it out, looks like in 4.1 we changed the behavior of the glTF loader to set the mesh side orientation based on the scene handedness. When we merge those meshes afterwards, we weren’t propagating that overriding side orientation causing the merged mesh to appear “flipped”:
Thanks for everyone’s fantastic investigation and response to this bug - especially @Drigax, when do you think the fix be propagated to the npm release?
it will be live on npm this monday
