Gizmo attaches to world origin (0,0,0) instead of expected mesh center after custom VertexData setup

babylon PG : Babylon.js Playground

The problem:

  • I expect the gizmo to appear at (10, 0, 10), because that’s where my quad vertices are centered around.
  • But the gizmo appears at (0, 0, 0) instead.
  • No matter what I try with setPivotPoint() or other methods, the gizmo always sticks to the mesh’s local origin.

My understanding:

Since the vertices were placed around (10,0,10) in world space,
I thought the local origin (0,0,0) of the mesh would correspond to world (10,0,10).
Apparently that’s not the case.

My questions:

  • Why is the mesh’s local origin still at (0,0,0) in world coordinates after setting VertexData manually?
  • How can I move the local origin or re-center the pivot so that the gizmo is correctly placed at the visual center (10,0,10)?
  • Is there a built-in method to “center the mesh” based on its bounding box or vertex positions?

Any help would be greatly appreciated!
Thank you for your support and for this amazing engine.

Cheers,
dev deet

It is two different properties. You have vertex data and you have a position vector. They are independent. There is no “origin” property. “Origin” or “visual center” is a human concept, here.

If you want a plane mesh centered at 10,0,10, just create it with MeshBuilder and set its position.

Anyway, working with your playground this should do the trick (but it will alter vertices): https://playground.babylonjs.com/#Z0S1NE#4


FYI, no idea how setPivotPoint() works.

Here is one of possible solutions - https://playground.babylonjs.com/#Z0S1NE#5

  1. Local vs. World Space: Meshes have their own local coordinate system that the gizmo references (so local position is still 0,0,0 after creation).
  2. Best Practice: Design meshes centered around (0,0,0) in local space, then position them in world space.
  3. Pivot Points: For complex cases, use setPivotPoint() to adjust the origin reference.
  4. Bounding Box: Always call refreshBoundingInfo() after modifying mesh geometry.

This approach will make the gizmo appear at (10,0,10) as expected, while maintaining proper mesh manipulation behavior.