Local coordinate systems, Pivots, Gumballs, Nulls,

Hello everyone!
From what I have gathered as a new user, in Rhino 5 objects do not seem to have an actual local coordinate system (LCS), like most other 3D programs I have used so far, do. Is that correct?

I’m recapping here something you guys surely know, for the sake of discussion - in 3ds Max, Maya, Cinema4D, Blender, Softimage (god rest it’s soul) etc. every 3D object has a LCS (a transformation matrix, data-wise) called pivot/axis/whatever. The translation part of the matrix defines the object’s center (where it is rotated/scaled about), and the rest of the matrix store rotation/scale/shear values. Whenever an object gets to be drawn, all of it’s points are transformed by the LCS first.
The matrix is always displayed in some panel, and can be edited, numerically, or interactively with some viewport widget.
Also, hierarchies can be built, which means that the children are also transformed by their parent’s objects LCS, cascadingly.
Additionally, some programs (Max, Softimage…) also sport a ‘temporary pivot’, which adds the flexibility to quickly rotate/scale around other points that the local pivot, so it does not have to be ‘destroyed’. (C4D lacks a bit here, btw…)

Ok… in Rhino, all this is kind of confusing… or let’s say ill-conceived?
The Gumball seems to combine a LCS and a temporary pivot, but in a peculiar way.
Because, if the Gumball is set to ‘Align to CPlane’, it stays permanent after relocating it, after deselect/select, and even save/reload(!), for all objects. But the moment I switch to ‘Align to World/Object’, the relocated Gumballs of all object ‘reset’. Not good!

Also, I would expect the BoxEdit panel to be the place to edit the transforms numerically, but only position and size are remembered/displayed, not rotation and scale.
Also, other programs can switch to all sorts of different reference coordinate systems (Global, Local, Ref, Plane, View, etc.). Rhino just has ‘World CPlane’ and ‘Current CPlane’. The most important missing here being ‘local’ - which I would expect to be the Gumball.
In fact, ideally, the LCS and the Gumball should be two different things, just like in Max or Softimage. The Gumball could reflect the LCS if it is set to ‘local’ mode, or be relative to some other reference coordinate system, but it should also work as a ‘temporary working pivot’.
Also, ref coord switching could be unified across the Gumball’s ‘Menu ball’ and the BoxEdit Panel.

Do I make sense so far?

Just checked Bongo… it adds pivots and parent/child hierarchies, but the pivots are sort of ‘proprietary’ - they are only used inside Bongo. The Gumball ignores them.
Also, the Bongo ‘Monitor’ panel is actually just that - a monitor, you cannot edit the values. So it’s no replacement for the BoxEdit panel.

I am willing to accept Rhino having a different approach to things, but after all, local transforms are a fundamental concept in 3D, and mighty as Rhino is, it seems to be lacking here. Or am I missing something obvious?

So, to sum it up, I would like to edit object transforms numerically, and use the Gumball to reliably reflect an object’s LCS, so I don’t have to relocate it all the time.

Are there any plugins/scripts? Maybe some kind of replacement for BoxEdit, where you can simply edit the LCS?
That would require that a LCS (besides the Gumball) actually exists - or do Rhino modeling tools always ‘bake’ the point positions to world space?
Any plans for V6 maybe to add a pivot/LCS, or refurbish the Gumball?

Secondly: In other 3D programs, there’s always the concept of a ‘Null’ object, a LCS merely. Do we have something similar here? Do Rhino Points store only position, or a complete LCS, so they could be used as some kind of workaround for a local pivot?

Thanks for reading and any insights!

Best regards
Eugen

I’m not exactly sure what you mean in the gumball stuff up there. But, in case you did not know, you can update the gumball to a specific view you are in. In this thread, it tells you how. I would like to setup macros to rotate say 15 degrees at a time, but also go back to the default cplane. I think I just need to learn more about named cplanes and creating saved cplanes and it’ll work just dandy. As of now, you can go back to your cpane with the undo cplane button after you reset your gumball how you like it.Gumball-Align to view

Also, it may not be exactly the information you are looking for. But there are two coordinate systems in rhino. Construction plane coordinates, and world coordinates. If you use the cplane as a theoretical pivot to the world plane, that is what it can be used for. So, they start off the same, but you can change your construction plane at any time in whatever pivot from the world plane you want. Then entering coordinates on that c-plane would be pivoted somewhat from the world plane. diagram of coordinates (except for uv-coordinates)

On a faceting lap, the pivots you are describing would be called “a cheater” All of the axes on the faceting unit are at certain degrees of rotation. A cheater allows all of those settings to stay the same, but rotates the entire mast assembly slightly on 1 plane to account for fixing a mistake and other uses. This keeps all the other angles locked.

You can also create multiple cplanes, or multiple pivots. You can save your cplanes. You basically you could pivot from world, pivot from that cplane, pivot again from that cplane, and so on to infinity?

Combined with relative coordinates, you should be able to make just as much or more happen with rhino.

Maybe this helps? I also gotta the thread a little more. I just wanted to get the links before I forgot about em.

Reading more into your gumball, named cplanes and resetting gumball macros are likely what you need(until a solution to your LCS type gumball is resolved). Also, I’m sure there are few features that are just as inconvenient going to another 3d software. For what I do though, I’m gonna stick to rhino as base for everything probably a very long time. There is software that is more user friendly for jewelry, but in a sense, you really do want to be able to design anything in 3d vs. only rings, bracelets, earrings, etc…If you intend to go off to 3d Matrix software right away with no base knowledge, its gonna suck when you want to design a machine to build what you design in it. With all around base 3d software, you can.

My understanding is individual objects in Rhino does not have “Local Coordinate Systems” and associated transformation matrices. Individual objects are defined using the global coordinate system along with object specific parameter schemes. Also the location for Gumball appears to be calculated “on the fly” based on the currently selected objects.

Blocks may work differently.

Thanks for the replies!
Looks to me that way, too - no local coordinate system. Isn’t that a huge restriction, or is it just me being used to certain concepts from other software?
In the end, it’s all about a smooth and quick workflow…
Given objects had a LCS, it’s very easy to monitor and edit position/rotation/scale/size relative to any coord system (world, CPlane, …) without having to place/relocate any Gumballs first. Relocating it means always quite a few clicks extra.

Especially size… I’m doing some architectural design training at the moment. Got lots of rectangular object (streets, ramps, floorplans, …) but with different rotations, also up/down, and I often want to change/check sizes numerically. Since objects are non-parametrical (without Grasshopper), you have to set the CPlane to the object before the ‘size’ parameter in the BoxEdit panel reflects the actual size. A LCS would save you the fiddling.
As mentioned, the Gumball actually CAN act as some kind of LCS, but only in ‘Align to CPlane’ mode, but that relationship is too easily broken.

Bongo adds a LCS to objects, the Pivot. For animation you need this anyway. I don’t animate at the moment, but I do miss the Pivot…
Data-wise a LCS is close to nothing. Just one matrix.

Does this make sense? -> feature request for V6?
Thanks!
Best regards
Eugen

Not a restriction at all for what I do, boat design and related. Probably just a different way of working than what you are used to.

Have you investigated using Blocks?

I agree with David. It’s not a restriction but I can imagine that it is a workflow to get used to.
Note, I don’t use the gumball nor the BoxEdit panel. From your description of the LCS, I don’t get the feeling I’m missing out on something :wink: .

Hi Eugen,
you have nicely summarized the situation, I think you haven’t missed anything. There’s neither LCS’s nor Nulls and also no native ways to create hierachies. For people with a strong background in mesh modeling apps and with the expectation to drive all transforms with the Transform Widget this sure will be quite irritating.

Indeed Gumball still is a young concept in Rhino (since version 5) and is offered as an alternative interface for interactive manipulation. In comparison to its counterparts in Mesh apps, which completely rely on these Gismos it will likely appear lacking. All traditional Rhino commands have setting temporary transform pivots built in (“select point to move from”), Rhino forgets about them as soon as the command has finished.
One of the reasons for the difference will be that creating a complex Nurbs model differs greatly from mesh modelling processes. There’s more item types, far more meaningful areas which lend themselves as pivots – one often deletes and recreates areas of the model – in the course of the process the program probably had to manage hundreds of action centers. Parametric solid modellers such as Solidworks do some of this by storing sketches, axes, planes and complete object hierarchy but the concept used here deviates greatly from approaches found in Maya and such.

For effectively learning Rhino when coming form a mesh background it might make sense to disable Gumball for a while. I believe it could lead on a wrong track.
Instead run Transform commands from the Toolbars and read what the command-line expects you to do.

Hi Eugen,
Holger and others have already explained things quite well.
But I’d like to add some chat … :wink:
Yes, Rhino objects have no LCS, nor history nor hierarchies per se.
Rhino has always been simple, trying to be easy to use and avoiding all unnecessary complications.
OK, obviously Rhino users don’t fully agree on what is necessary and what is not … :wink:
Rhino has also been from the beginning a general purpose software, meaning it can be used (and it is used) in several different areas. That also means that it is not perfectly fit for any particular purpose.
In a way or another you’ll miss something, anything you use it for … generally speaking.
But Rhino also offers several workarounds to let us customize it, if we need it or like it.
As far as I understand, you usually work with clearly identified objects that you often have to move, scale, etc.
But Rhino is also used differently, sometimes with thousands of curves and surfaces for which individual LCSs would be a waste of space and individual transformations might mean a waste of time in Rhino’s calculations. Also all those LCSs and matrices would be useless in that kind of work. (Just my humble opinion here, maybe I’m wrong …)
Rhino relies on independent plug-ins for features that it does not offer.
Unfortunately I don’t know about plug-ins that do what you’re looking for.
You might want to look at Food4Rhino.
Things that may help in bending Rhino to a particular workflow are:
Its customizable user interface: you can build, hide, show, arrange, edit toolbars as you like.
You can build you own buttons (and aliases).
You can use macros and scripts and Grasshopper definitions
And for object hierarchies (well … not quite. Sort of) there are layers (with sublayers), blocks and groups.

EDIT:
… and obviously CPlanes … they are the only kind of CSs Rhino has … unfortunately :smile:
/EDIT

If there are actions that are particularly complex to do in Rhino, don’t hesitate and ask here.
We’ll try to find an easier way … but no promises, sorry :wink:

BTW, as Holger said, the Gumball is still young and is being actively developed in V6

Cheers
emilio

Hello!
Ok, thanks, I hear you. But: if the Gumball is so… superfluous, why did McNeel bother implementing it?
I just use it for what it’s meant: transformations. Move, rotate, scale, and size (via BoxEdit). That does not mean that I want to ignore the other tools, how they work, or that the Gumball should be a replacement for everything. It’s just a handy dandy addition. But it does not go all the way - yet. I bet that we will see improvements here sooner or later, because it makes sense.

Newbie question: how do you numerically change an object’s size without the BoxEdit panel? Like: you, object, now be 5m long instead of 2.345. In other words, is there a 1D/2D/3D scale with the option to enter the target size, not scale?

The moment you use BoxEdit for this, you will need to set the CPlane to the object to see the correct bounding box, and that’s what I’m talking about. If objects have a LCS, there would be no need to fumble with CPlanes (which is no problem, I do it all the time, but it’s extra clicks).

Some general chat:
After 20 years of sticking my nose into various 3D programs, countless hairs pulled, and after having coded numerous plugins and scripts for Softimage, there is one thing I would ask developers: never force a certain workflow upon users! Give them options, let them choose how they want to work. In user interfaces there’s always room to make things smarter and simpler. Rhino is cool! But let’s not stop in the middle.
This goes for any new tool in any program: don’t like it? Don’t use it. But let others.

Anyway, happy modeling!
Best regards
Eugen

I wanted to add: I really like that!
A LCS, however, is nothing complicated. Neither are matrix calculations particularly slow. If I’m not mistaken, they are part if the CPU instruction set these days.The hardcore Nurbs math that works under Rhino’s hood, though, is complicated. But ok, we are talking about user interaction here, not internals.

Talking about Blocks: very handy! Instances exist in pretty much every 3D program I know. But it would be nice if it was possible to also rotate the base point, not only set it’s position.
Looks like Blocks have a LCS anyway. How else could ‘Reset Gumball’ in ‘Align to Object’ mode find the Block’s base point position AND rotation otherwise?
Since this concept seem to exist already in rudimentary form, let’s go all the way.

Eugen, Emilio,
It’s not that Rhino keeps things simple or that “every other 3d software” have these capabilities…
There are historically two big families of 3d software: DCC (Digital Content Creation - such as 3dsMax, Maya, Modo) and CAD (Computer-Aided Design - such as CATIA, SolidWorks, Pro/E).
LCS are found in DCC software, but CAD software often have similar concepts or tools when moving parts in the context of an assembly.
Rhino has more of a CAD background but has users in the two worlds and tries to keep everybody happy without going into very specialized tools.

Here the temporary pivots I mentioned come into play. When running Scale 1,2,3 one either may input factors, that’s the default option – or you may pick a reference point and by that call an alternative version of the command. In your concrete example one would run scale 1D, picked one endpoint on your 2,345 box and then would select the opposite point. Then you may either pick a second reference point (freely in space or by snapping to items) or you can input 5 (if your unit is meters). What’s nice is that you don’t even need to know the present size of the object, clever choice of the origin point (pivot) makes the command quite flexible.

Generally speaking, the object doesn’t know it has a length. Even a box, you created with the Input of width, lenght and height is just a dumb collection of surfaces that happen to be pairwise parallel and have a distance, you just entered.

You can use the Gumball to simulate something similar: Relocate the Gumball to be on one of your faces that define the length. Now align it to the face and extend the scale handle to the other side.
Once you start dragging the scale handle, you can enter a numeric value that sets the distance of the handle to the Gumball origin. So the other face will end up at the distance, you just specified, effectively setting the “length”.

(Make sure you use Snappy Dragging mode)

Nice tips, thanks!
A-ha: Scale/1D/2D take both percentage AND absolute value, depending on if you pick a second point before entering a number. Nice!

Gumball: CTRL-drag works not only for it’s position, but also rotate and scale handles! Didn’t notice that.
I knew that typing values while dragging a (move-)handle sets the relative position - but, logically, the same goes for rotation and scale… good!

Yet to type in values while dragging, you have to hold the mouse button, and thus type the numbers with the left hand (if you are a rightie). Hmm… is that convenient?

Also, the regular Move/Rotate/Scale ask you to pick a start reference point, always. Yet if you worked “axis-widget-centric”, like all the other programs, the start reference point would be the axis widget (=Gumball here), and if the axis was already in the right place, there wouldn’t be the need to set it first, so you save clicks.

I’m still not convinced that the standard-Rhino way is really better or faster… nothing’s like a well thought out axis widget!
The Gumball has a future, if you ask me.

I’m working on a laptop so no num pad, no inconvenience. On a totally unrelated side note: If you are using rhino in a different locale as your OS (my Rhino speaks English on a German pc), the num pad is useless as the decimal point of the num pad seems to be hard wired.

Right, I’m using an english Rhino on a german system. The num pad comma does not work, I noticed.
Shame… that old problem.
Cinema4D, btw. does not care if you use . or , it accepts both as comma.

How does it figure out whether to interpret nnn,nnn as either a decimal number or an x,y coordinate?

–Mitch

It doesn’t have to. You can only edit one single number at a time.

Pretty easy to appear more flexible then :o)…
In mesh apps coordinate entry typically may only happen in editors similar to Box Edit, transform widgets don’t accept number entry either. Rhino however supports entry of 3D coordinates in via command line too, both in absolute and relative notation. For that reason one needs point as well as comma.