Hey, I’m having some issues with 8.28.2 onwards with animations.
when I attempt to play a custom animation group babylonjs crashes (grey screens) but doesn’t give me an error. This only happens when built for production (I’m building in NextJS). The reason I think it’s import based is because if I import the whole of core everything works fine. Previously I had to import @babylonjs/core/Engines/webgpuEngine and @babylonjs/core/Animations/animatable to ensure it worked but now that’s not enough.
Looking at what changed between the 8.28.1 and 8.28.2 I see chunkFormat was set to false, I wonder if this has changed the imports of some side effect imports.
I’m not really sure what my desired outcome is, either treeshaking is fixed so I get what I need again or we work out what I actually need to import directly
.
Thank you 
Hey @link2twenty, thanks for letting us know something regressed! I don’t think it could be the chunkFormat change as this is only part of the WebPack configuration used when we pre-bundle the UMD packages, but from what you mention above, you must be using the ES6 packages (which are not pre-bundled by WebPack, they are just .ts compiled to .js).
I would also guess as you suggest though that something changed related to side effects such that something previously included in your bundle is no longer included. The diagnose this though we’ll need more info.
- To be clear, if your code and your own bundling configuration is the same and all you change is the Babylon packages from 8.28.1 to 8.28.2, it goes from working to not working, correct?
- When you say it “crashes (grey screens) but doesn’t give me an error” do you mean there is no unhandled error? If so, can you try enabling “Pause on caught exceptions” in the Chrome debugger Sources pane and see if there might be an error that is not bubbling out but should be?
- I assume there are no errors or other useful information in the console?
- Is there any way you can provide some kind of repro that can be built and tested locally?
Right, my initial assumptions were all totally incorrect but something funky was going on.
I’m using easy-prop-animation which works out animations for you based on what properties you’re changing. This section of code works out the Animation dataType for you. For some reason Both Vector3 and Color3 were getting the same name in the build.
I’ve fixed this moving to checking with instanceof, which is heavier but a lot more robust.
private static getAnimationType(value: unknown): number {
if (!value || typeof value !== 'object' || !value.constructor) return Animation.ANIMATIONTYPE_FLOAT;
if (value instanceof Vector3) return Animation.ANIMATIONTYPE_VECTOR3;
if (value instanceof Quaternion) return Animation.ANIMATIONTYPE_QUATERNION;
if (value instanceof Matrix) return Animation.ANIMATIONTYPE_MATRIX;
if (value instanceof Color3) return Animation.ANIMATIONTYPE_COLOR3;
if (value instanceof Color4) return Animation.ANIMATIONTYPE_COLOR4;
return Animation.ANIMATIONTYPE_FLOAT;
}
It is strange that it broke only after 8.28.2 (it worked again on downgraded) but hopefully it was just an extreme edge case and everything’s actually fine 
1 Like
I see, I think the code you linked is basically never safe to do, and I would guess that the reason this broke between versions is because of changes to dynamic imports caused the bundler to output different chunks. For example, given bundling + minification, you could end up with Vector3 and Color3 in two different chunks. If this were the case, the minifier could rename both classes to a for example (because a would be unique within each module scope). Then when Vector3 and Color3 are both imported into another module, the bundler could generate code like this:
import { a as a1 } from "./chunk1"; // Vector3
import { a as a2 } from "./chunk2"; // Color3
console.log(a1.constructor.name === a2.constructor.name);
In this case, both classes have the same constructor name, and so the code you linked would treat them as the same class. A simple change to the code you linked would be to compare the actual constructor itself rather than the constructor name, as that would work regardless of any minification. Something like:
const instanceToType: Record<string, number> = {
[Vector3]: Animation.ANIMATIONTYPE_VECTOR3,
[Quaternion]: Animation.ANIMATIONTYPE_QUATERNION,
[Matrix]: Animation.ANIMATIONTYPE_MATRIX,
[Color3]: Animation.ANIMATIONTYPE_COLOR3,
[Color4]: Animation.ANIMATIONTYPE_COLOR4,
};
return instanceToType[value.constructor] || Animation.ANIMATIONTYPE_FLOAT;
This would avoid adding the “heaviness” of instanceof.
1 Like