Confusion on use case for Center of transformation, pivot, parent/children

Hi,
I’ve been working through the documentation on mesh translation and wanted to ask for a suggested approach to using some of tools available.

Users bring in meshes which may have large local offsets (the actually geometry may be far away from its local origin). They then select a point to move the mesh to the world origin. After that they apply rotations to the mesh from the world origin. Once the mesh is positioned properly it is used to extract measurements from, as a guide for new geometry, and/or exported.

Given that and the tools offered, I’d like to gain some perspective from the members on a high level approach. I have worked out using each of the tools for the most part and will get a playground going to complete this post. It is important to bake in the transformations into the local mesh by the end of this process.

Right now I’m working on several approaches and I am unsure which one below (or others) is the right one to develop further. Your thoughts are greatly appreciated.

Approaches:

  1. A user picks a point, the point is used to set a pivot, the pivot is moved to the world origin, the pivot is used for rotations, the final translations are all baked in, and then the global offsets (from pivot to world origin) are reset.

  2. User picks a point, a parent mesh is created as a container, most of the steps below are followed but the parent mesh translations and rotations are used in place of the pivot.

  3. Apply translations to the mesh by baking them each step of the way → I think this is the slowest method as the meshes have many points that need multiple dynamic translations (user interaction, sliders, etc).

  4. Use transformation nodes / coordinate transformation then bake in at end. The user picks a point, the point is used as the CoT and moved to the world origin prior to baking in. I think this is the best approach?

Thanks for your review.

We do have a master on that topic with @JohnK :slight_smile:

I would like to know more about what measurements will be extracted.

Hey John,
Thanks for joining this. The measurements are made through ray intersections at several locations relative to the origin. For example the max X and Z value at several Y values (slicing the mesh at critical locations). The great Evgeni_Popo helped guide me to a working solution (see below).

The locations along the Y axis are relative to the origin (for example 10 cm up from center, 100 cm up from center, etc.). The measurements and an stl are exported for use in another software, this makes it critical to manage the location of the origin → set by the user picking a location in the mesh.

Does this help? I am starting a generic playground to help show more of this. There are implementation and behavioral differences in the approaches above that I haven’t worked out as far as which to use here.

Ultimately the user imports a mesh that can have a random assortment of offsets and rotations - I’d like to fix all that. The user picks a specific point to define the center. Rotations are used to orient the mesh. Some of the mesh is cut out by isolating what’s in a box around the origin, everything outside of the box should be deleted. Once the isolation and translations are performed, measurements are taken (ray cat intersections) at critical locations relative to the origin orientation.

Exporting the stl and measurements is done for another tool to work with. The new stl should reflect the user selected origin, orientation, and isolation (inside the box).

I do appreciate your review and guidance. I’m still working out this PG and using this post and feedback to approach it.

Thanks.

As a good example PG, I’m going to try and move one of the stanford bunnies ears to the origin (by picking a point at the ear hole) and oriented (rotations applied dynamically with a slider) with the tip of the ear facing up and forward.

PG below moves the mesh from a picked point to the origin using a center of transformation. After that you would use the slider to rotate the bunny. When I do, it uses another location in the mesh and not the transformation.

Also, when using the Pick Point adn Point to Origin multiple times the point seems to “drift” or stray from the origin.

Thanks.

Okay so this PG is working by baking in the CoT, although baking in the scaling changed its visual size which surprised me. It’s close but is this the right track? Also still has the bug where the point to origin only works the first time…

some earlier versions:
https://playground.babylonjs.com/#95MJI8#380

Here I try to create a new CoT to enforce the rotation but it seems to revert to the bunnies local origin… Maybe I have to bake in the first translation or update the world mesh?..

https://playground.babylonjs.com/#95MJI8#381

PG with non-working parent/child https://playground.babylonjs.com/#95MJI8#384

It is the pre-scaling that needs to be taken care off when applying CoT. Will have time over the next day or two to look more into it.

Great to hear you’re looking. I have noticed unexpected responses around my use of scaling. I’ll keep at it and look forward to your review.

Is this close to what you are after? https://playground.babylonjs.com/#95MJI8#386

1 Like

This looks great. I appreciate your help.

A few observations:

  • I like your approach and usage of the built tools subtract, pivotAt, translation.
  • Using the move_to_origin doesn’t seem to work more than once unless the vertices are baked in.
  • After import the bounding box of bunny is the small non-scaled value
  • When performing the translation the world coordinate point is divided by the scale
  • Baking scaled the bounding box (vertices which here grew the box).
  • I need to do more research on scaling as it relates to the scene, translations, and pivots

I’m going to see how well this works outside of PG.

Thanks again - HUGE help!