Native MoveToOrigin?

A frequently asked question : Is there an easy way to move an object to the World Origin.
If I am not wrong, this is not implemented yet…

Having access to a native tool with a behaviour similar to the nice script posted by Helvetosaur would be so helpful…

No need to add unnecessary options, using the center of the object’s BB as the starting point will be suitable in most situations, right ?

The simplest, the better…

  • Take any object
  • Hit MoveToOrigin , Enter
  • BAM !

With a keyboard shortcut that would be sooo easy.

I would like to have your opinion or comments on this subject.

Thanks you in advance for any contribution.
Rodolfo Santos

if you drag and hold an object either just a mouse drag or with the command move from any point and hit 0 space/enter/rightclick (as in coordinate) it will relocate your object at the desired point of origin. that also works with gumball, drag the object at the gumball center and hit 0.

you can also macro the move command make a command out of and access it via hotkey.

@encephalon

Correct, but this approach drives to a manual procedure.
On the other hand, it is not always easy to find center of the BB depending on the type of object .
Then, if the object is far away from the origin, travelling across the view can be constraining.

The questioning is : Does it makes sense to get the intent ( move to origin ) facilitated trough the use of a native command instead of trying to find a work around solution.

Regards
Rodolfo.

i honestly dont think it would make much difference, the methods described above are fast and sufficient. and a native command would imply selecting the object, hitting a command button which in most cases would be 2 buttons. using the methods described above have the same amount of steps.

what i would be happy about though is to import an object at the center of the camera focus not to move to an fro when importing stuff for instance 3d people in a scene. like so i have to zoom and swivel and drag/move which is rather bothersome if done repetitively.

Thank you for you answer.

You are pointing the number of steps, which is one concern.

I am pointing the fact that using the Move tool implies having to define a starting point, which in most cases, when we want to move the object to the origin correspond to the center of the BB or the Volume Centroid.

Another option would be : If the native Move tool had an implicit value ( by default ) set to the center of the object’s BB, we could then skip the PointToMoveFrom step, then hit 0
…Or create a macro to automate things.

Make sense ?

Regards
Rodolfo Santos

then just dragg the object without using move in the end you will have to select the object meaning you click on it. its all the same plus minus a few extra turns in the brain at max :slight_smile:

dragging the gumball centerpoint and hitting 0 is pretty much that.

also check this, you are not alone in that request. if it makes more sense i really dont see much difference…

edit: ok i guess the last link might be a bit different contextually.

Works well with one object.
What if you start to work with a set of objects that are selected by names, colours… then you probably will need to call the move command or got for the Gumball.

That exactly why I think it would make sense to add that behaviour to the Move tool.
The Gumball is a fantastic tool, but selecting it dead center on small objects is sometimes a mess.

Also, being using a mac, here’s what happen with this procedure :
Select object
One finger to Left Click on the pad
Move Objet a bit
Slide a second finger on the pad
Type 0
Leave the pad with the second finger, press Shift (Second finger) + 0, hit Enter.

Sooo funny to do just to relocate an object @ 0,0,0.

As I said, we can find work around solution but in terms of usage…

I will read the linked topic, thanks.

Regards
Rodolfo.

do you really want to stack several objects simultaneously in the origin? and then? who is going to clean it up? :smiley:

using a pad or a mouse is not much difference, but ok i prefer the mouse because that just feels better controlled. i am also using a mac but there are certain things apple introduced which i just cant get over with…

Stacking is naturally not the intent.

When selecting multiple objects, the Gumball permits to move the group from the BB center to ie. layout on the ground (at the origin) objects located somewhere else.

Regards.
Rodolfo Santos.

Dear Rodolfo

you may also consider:
_boxEdit
_align
check the help for all the power those tools will give you.

and i think @encephalon gave you a great answer. - i think his first post is the solution. - you should mark it as so.

Rhino offers a huge amount of approaches from macros, shortcuts, scripts, plug-ins …so you can personalise the “flow” to your personal needs / habits… And in the end, there is a certain amount of how an application feels, of course there is a certain spirit from the developer side.

And i think the tool-set for transformations in rhino is really great.
http://docs.mcneel.com/rhino/7/help/en-us/index.htm#seealso/sak_transform.htm

i don 't miss anything there.

hope this helps. kind regards. -tom

Just wanted to throw in here that objects in Rhino do not have an implicit ‘center’. It may look that way when you select the object and the Gumball centers on it, but in fact the ‘center’ you see - which is more properly called the ‘origin’ - actually belongs to the Gumball and the bounding box that it calculates, not to the object. The Gumball origin can also be moved where you want. It is for this reason principally that Rhino doesn’t have a 'Move from object center to x,y,z function" - objects don’t have ‘centers’.

The theoretical center of objects can also be calculated in different ways with different results. Gumball (and a number of other methods) use the bounding box center because it’s reliable and quickly calculated. For planar curves plus surfaces there is also the possibility of calculating an area centroid; for volumes one can also calculate the volume centroid. These can be somewhat less reliable than a bounding box and take longer to calculate.

Lastly, as Tom said

Windows Rhino makes adding a new toolbar button with a script or macro extremely simple, a matter of a few seconds. MacRhino is a bit more painful in this regard unfortunately. Aliases are also easy to set up on both platforms. The possibility of personalizing your workspace/workflow is one of the most powerful features of Rhino.

In math a centroid is defined for and can be calculated for any curve or surface, planar or non-planar, open or closed. Rhino however limits centroid determination to closed planar curves (which it assumes define a planar surface), surfaces/polysurfaces and “solids”.

The centroid of a curve is the volume centroid of a closed, constant diameter pipe around the curve when the pipe has infinitesimally small diameter. Calculation of the centroid of a curve is simple requiring only two simple intergrals/quadratures.

Correct but why forcing the user to
1 - Select Object(s)
2 - Got to the Box Edit Tab
3 - Change the Position Coord
4 - And the most constraining : Hit Apply

I mean, this is not a fluid approach when modelling …

Sorry I don’t get this one in regards to the discussed intent.

Ok,

! _Move
Then how do you tell Rhino to start from the BB center ?

No macro, no shortcut…

That exactly what I don’t like when the intent is to do such simple tasks and I am not a unique case.

I totally agree.

Totally agree and this is what is questioning me a lot.
Based on the fact that BB center is so reliable and quickly calculated, can someone tell me how to create a macro that will allow me to select any object or group of objects and ask Rhino to move that object or group of objects to the origin, starting from the implicit BB center ?

Then I will be able to create an alias and Voilà.

sometimes, the use must prevail.

I totally agree with all your suggestions and I am tankful for that, but no one is convincing me.
Simple task, simple tool. that’s my spirit.

Regards
Rodolfo Santos

That’s good information - however, in practical application within Rhino, in my experience there are more failures to calculate a centroid than a bounding box, and if the object is something like a complex mesh, the calculation time is a lot longer.

Thanks you for the objectivity of this remark.

Regards.
Rodolfo Santos.

In some situations yes, but in many situations no. Moving a building or furniture may need the bottom of the moved object to be at z=0. Other situations may need the moved object to in the positive x, positive y, positive z octant.

Unfortunately macros are just too limited to do this - in theory, yes, it should be simple, but it isn’t. One can calculate a bounding box and get its centroid, but that information is only available via a text output to the command line or a point object in Rhino. The point object is not able to be used as a ‘from’ point, the text output might, but it requires parsing the command history.

The limitations of macros is what convinced me to learn some scripting.

I agree with David. Most of the time the ‘center’ of an object is not a precisely known or practical place to move from, I almost always use object snaps from a known point on the object.

@davidcockey
You are right, architecture and furniture design are relavant examples, but these should not be used as a generic approach, right ?

There are, as you mentioned, some situations where the needs are different.

Regards
Rodolfo Santos

Thank you.
I understand the logic behind that and I accept it.
I just hope that the frustration that this may implies will be heard.

Regards,
Rodolfo Santos

i still dont see much sense in having such a command. you can if not meant to be stacked and just an array of objects in the same distance to each other, the gumball center of all the selected objects would then beam them all to the origin with the 0 coordinate.

anyway you should consider marking this as Wish in the Topic Title, maybe it will get more attention then.