When was 5.0.0 beta2?
I’m also having a merged meshes issue (with clones) since about 3 weeks. I remember it happened after a nightly update on a friday (I think 3 weeks ago).
@RaananW is aware of it and said he would have a look into merged meshes next week. May be this can be added to it. May be it’s part of the same.
When was 5.0.0 beta2?
about two months ago
OK, well my problem occured as I said only about friday 3 weeks ago. Before that was working fine.
Edit: Apologies, time is running
From my files, the problem occured since February 26. If this can help track it.
I’m actually having a look right now
Awesome, thanks for lightning fast fix ).
Does this fix solve your issue as well?
Sadly no, not just now. I believe I will have to check on it again.
I run to this same problem when merging meshes after importing GLB-file. I’m using BabylonJS v5.1.0.
Edit: It is not related to transform. The transform is actually correct. The material orientation seems off. I’m working on it
Ok sorry it will be fixed with next release
This PG of the bug does not work and it is expected because you need to reset the overrideMaterialSideOrientation:
Blender Mesh Test | Babylon.js Playground (babylonjs.com)
mesh.overrideMaterialSideOrientation = null;
This is because that value works with the previous material but as you removed the material you do not need to override the side orientation anymore
I’m still having a problem with my merged clones in my project
Once my pr will be merged you should be good
So let’s say you can retry on Tuesday?
Got it. will do. Meanwhile, have a great WE.
With latest version of BJS MergeMeshes seems to work now as expected - thanks @Deltakosh !!!
Isn’t this going against backwards compatibility?
In 4.2 it only works without mesh.overrideMaterialSideOrientation = null;
but now in 5.2, it only works with mesh.overrideMaterialSideOrientation = null;
I checked using your PG.
Having upgraded Babylon three times, now I’m really afraid of it, because something always breaks.
Each time I wasted at least one to two days of unnecessary debugging. Then followed by several days waiting for the released fix to be on npm. Usually accompanied by dirty quick fixes while waiting (manually changing code in npm node_modules before bundling) in order to release to production.
I mean breaking changes between versions is normal, as long as they are clearly stated in Change logs, and without promising people that it’s backwards compatible.
I can’t agree more. This was a bug we fixed (the 4.2 behavior was actually buggy. It may have worked in your case but was buggy on other cases.
We are really trying hard to protect backward compatibility as this is core and central for me personally. Unfortunately, we are only humans and sometimes we fail.
This is a failure.
What I can promise you is that we will try to improve, and we are always here to help in the meantime