Move GH geometry back to original location

I sometimes import geometry into Rhino with a coordinate system that’s flipped, and I so find it much easier to re-orient the part so that the plane I’m working on in GH is the default XY plane. I do all my GH on the re-oriented part then when I want to export my GH I need to bake the geometry and move it back to the original location so that when I export it comes into the original CAD software in the correct position.

At the moment I’m moving my baked geometry back to the original position by hand and it gets a bit tedious, would like to automate. I also don’t want to do the initial re-orientation via GH (I know if I did I could reverse the transforms but I’d prefer to do this initial step of moving in Rhino).

Any suggestions on how to get my GH back to the original position? Box orient doesn’t work (doesn’t maintain orientation). Can GH access the transforms applied to an object in Rhino?

Inverse Transform, something like this should work?

[edit] easier with a video explanation :slight_smile:

1 Like

Basically you need to deconstruct both BREPs, measure areas of all surfaces, isolate two unique faces close to each other, find three points to create a plane and use the Orient component to move the object back into the initial location. Unfortunately I don’t have a definition to share.

1 Like

This doesn’t work, though I can imagine cases where it might, depending on what changes are made to the geometry in the “moved position” (Brep (MP)).

I believe a solution is indeterminate based on the problem as stated.

P.S. One slight change gives a better result in this case. Removing “reverse” from the List Item ‘L’ input so the smallest surface of the bounding box is used instead of the largest.

This version uses MIndex to avoid any ambiguity that might be caused by Sort, though I don’t know if that’s a problem?


move_geo_2025Feb7c.gh (22.0 KB)

Seems like with the bounding box the faces of the same area get mixed up and final re-oriention isn’t always correct. Attached code has internalised breps.


bounding.gh (244.3 KB)

Yes, it would work if each face had a unique ID (GUID?) that doesn’t change, but I don’t know how to do that,

A little late, eh? :roll_eyes:

1 Like

What I like about this is that instead of drawing that initial plane I can create a 3-point surface and use that as the source plane, then just move the surface along with the copied brep and reference that surface back in as the target. So long as I move the brep+surface the re-oreintation is good.

I just wasted considerable time searching for how to obtain a Guid for each face of a brep. Maybe it’s impossible for internalized breps? Discouraging that it’s so difficult :bangbang:

Reminds me of Tesla’s way of developing FSD (Full Self Driving) at the expense and risk of their customers. :frowning:

1 Like

Yeah - seems like as soon as it’s internalised and exploded it doesn’t recognise the faces.

In this case, it works to skip the bounding box: (that may not always be true)


move_geo_2025Feb10a.gh (250.5 KB)