Question about Mesh.bakeCurrent TransformIntoVertices

I ran into a problem where Mesh.bakeCurrentTransformIntoVertices is causing the mesh’s children to move to world space, like they have no parent. Mesh edges are behaving the same way. See this playground:

Ultimately I am trying to use the STLExport from babylonjs-serializers which calls bakeCurrentTransformIntoVertices() for each mesh. After the export all children in my scene are moved to world space instead of local to the parent.

Any help is greatly appreciated.

Ping @Drigax as it sounds to be an issue with the exporter, I guess they should be baked from leaves to root to prevent the issue.

Ok if I understand correctly, the right way to bake is to bake the child first, then parent? What about box edges though. In the playground I posted you can see the box edges having the same problem after being baked. Is that a bug in the box mesh where it should internally bake the edge lines first?

About Cylinder and box yes but I am not even sure the edges renderer could be serialized this way :slight_smile: I was more considering it like a tool like the gizmos or an highlight layer.

We should look into this part as well.

This seems to work then for my export routine:

  • disable all edges
  • bake all meshes (leaves to roots) Pre-baking seems to work-around the problem since the children will be baked in by the time CreateSTL is called.
  • do the stl export STLExport.CreateSTL
  • enable all edges

@sebavan Thanks so much for your help!


Hey Seb, looking at the code for Mesh.bakeCurrentTransformIntoVertices():

We reset the Mesh’s orientation and world matrix, but don’t perform the inverse operations on its children. This doesn’t seem like a good idea in general, since we can’t bake an individual meshes data without cascading the transform changes. I’d argue that we should change that behavior to address this, or at the very least provide a toggle to do this independently of children

Working on a fix now, but I’m slowed down a bit. There doesn’t seem to be a good way of setting worldspace transform components in Babylon, I’m currently working on some implementations for NodeTransform.setAbsoluteScaling and NodeTransform.setAbsoluteRotation. Manually setting the _worldMatrix of the node seems to be unreliable, as we overwrite it the next time it’s computed, and I’m not sure if we want to indefinitely freeze the transform, do we?

@sebavan, @Deltakosh got some suggestions?

Well I think this is not the expected use for this API :slight_smile:
Baking the transform should actually detach the children beforehand with child.setParent(null).

It’s a little strange that we expose world space position, but not the other two components. Regardless, I think I have a non-destructive solution to this, since I don’t necessarily want to set world space transform, but local space transform relative to the baked node’s parent. I should be able to do something along the lines of:

for child in mesh.children:
       bakedMatrix = child._localMatrix.multiply(mesh._localMatrix);
       bakedMatrix.decompose(child.position, child.rotation, child.scale);

because position is fast to decode whereas rotation and scale no. It is mostly a perf reason

1 Like

Makes sense, I can’t quite think of a good reason why one would really need to do this other than maybe IK constraints?

PR for the fix is here:

and a repro test scene can be found here:

1 Like

Just merged. This should be in the next nightly :slight_smile:

1 Like

that is because stl formats do not support local space, its only global positions,normals and indices information I believe. It was like 2 years ago or more now that I made the exporter and if there are some new features that are needed please tag me and Ill get on it right away.

Yeah I just double checked, STLs only support normals, and triplets of points in global space. There are workarounds though if you really really need stls to do more, it just requires some custom parsing.