Adding a per-object frame (origin, x, y ans z axis)

In Rhino 6, we are considering adding a per-object frame as an object attribute.

Any changed that are actually made to the product will be described in the Rhino 6 bug issue RH-27397.

The goal is to provide a single clear and well defined place for “the” object’s frame to be saved and a well defined way for scripts and plug-ins to use this frame. The default frame would be “unset”, which means that a user has to do something to get a frame applied to an object.

Conceptually, Rhino has several per object frames in place now.

  • Gumball - The frame that appears when you select a singe object and display its gumball.

  • Texture mapping - The frame that appears when you apply a “planar” mapping using the “ApplyPlanarMapping” command.

  • Scripting - The RhinoScript commands like CurvePlane and SurfaceFrame are returning a per object frame.

  • Bongo - The object frame used in animations

  • commands that take an object as input and return some sort of plane. The “Curve”, and “Surface” option on the CPlane command are examples. Note there is also a “Gumball” option on the CPlane command.

  • I’m sure there are others …

The current thought is that the frame the gumball is using will become “the” object frame and the gumball will be the primary interface.

There are lots of questions about how an object frame would actually work.

  • If an object has an explicitly set frame, what should happen to the frame when the object is edited in a “squishy” way (control points, bend, twist, …)?

  • There will be cases where “the” frame needed for editing (gumball), rendering (planar mapping), animation (Bongo), … are different. How can this situation be gracefully handled?

  • What is the “Default” frame? Should the active view or cplane play a role?

  • Some objects, like planes, extrusions, circles have an intrinsic “obvious” frame. Some commands that create objects, like sphere, have an “obvious” frame while the command is running, but that frame is not so obvious after the command finishes. Should these commands set “the” frame?

I’d love to see the frame be set to something sensible on objects instead of “unset”.

I’ve been trying to create a cut list for lumber for a fence I’m building. Some of the pieces are not world-aligned boxes, and so getting the size of the box from Rhino is a chore. If the frame were aligned with the box during creation, and if the frame transformed with the objects, then I could use the frame as input to Rhino.Geometry.GetBoundingBox(plane) in Python, and get my answer straight away.

1 Like

Dale - what was the rationale behind leaving it unset at first?

The rational was that is the way the current cached frames work and so that’s what I thought a good starting spot would be. I think the user experience goal is for the frame a user gets the first time they ask for it to be the “obvious” one. How this experience is implemented could happen in several ways.

From a user an scripter perspective:

  • +1 for the object frame being set at object creation for every object as a default (implicit). We have been missing this feature many times.
  • For most of our use cases setting the frame to the bbx center on creation would be ideal.
  • The orientation of the frame during creation should be the world or cplane. Using a command to set this option globally would be our preferred way. This should also be setable by script functions that create objects.
  • Commands should not set the frame just for the sake of consistency. World or cplane orientation would be the preferred scenario from our experience.
  • Scripting functions that create objects and require a frame for creation could accept an optional boolean parameter set_object_frame parameter. If true the frame supplied for creation would be stored with the object otherwise the default world frame is used.

More thoughts and discussion:

As I envision it, “the object frame” is an object attribute and can be set/unset at creation time and can be modified at any time. Currently most script/plug-in SDK object creation tools have an option to override the default object attributes when the object is added to the current document.

When a calculation needs a frame and it’s “unset”, the “obvious” frame is returned. I think a good candidate for the “obvious” frame is the world axes aligned frame with center at the object’s world coordinate bounding box center.

If the frame is always set at creation time, then for objects like curves drawn from control points and then edited by dragging the control points, the preset frame becomes something between useless and confusing.

I think there are important exceptions and objects like boxes, cylinders, rectangles, circles and so on, jump out. In these cases, there is a clear choice of an “obvious” initial frame. The commands that create objects with obvious initial frames, could set them at creation time. Most annotation objects also have an “obvious” initial frame.

Anything that depends on a cplane also depends on what view happens to be “active” at the time of the query, since each view can have a different cplane. In many commands the “active” view at the time the objects are created is simply the one where the last mouse click pick and can be different from the view when the command started, the view when the command ended, or the view where picking occurred during the command, or the view the user may think is the “obvious” view. For example, when a line is drawn the end points can be picked in different views, neither of which is the view that was “active” when the command started. Because the determining “obvious” cplane is not easy, I’d like the first prototype to use the world axes as the “obvious” orientation and go from there.

Any script, command, or other “code” can set “the frame” at any time. (Any object attributes can be modified at any time.) The current object attributes changed event watcher hook could be used to detect frame changes.

It won’t take too long before different commands/scripts/calculations start setting and using “the” frame in ways that are incompatible. I’d like to wait until we have some real world examples before we decide what to do about this issue.

This behaviour to me seems what I would have expected. Maybe it is my background with the animation software Maya, where there is a geometry node and a transform node (the frame) that are both visible to the user through a UI properties panel (and a visual programming like graph). I would be very happy if the per-object frame idea you present could become something like Maya’s transform node. It would register and store all classical transformations (move, rotate, scale, shear) that an object lives through.

To eliminate the point editing problem leading to confusion, e.g. when the frame is very far off, there could be a ResetFrame command. It would re-center the frame to the object’s bbx, with an optional parameter to reset other transformations registered with the frame as well.

Would it be possible to implement this as an optional bahaviour that can be toggled on and off? A consistent frame setting behaviour for all objects would be preferrable from my point of view.

Consider this:

  1. I draw a box (The frame is not set)
  2. I rotate the box (The frame is still not set)

If I ask for the frame, you give me the world aligned frame centered at the bounding box centroid. This is useless. I’d rather it was aligned to the box that I created the first time.

Brian, Further down in my reply I discuss handing objects, like circles, that have obvious frames. I think “box” is in the category of an object with an obvious initial frame.

Why bother being inconsistent about it? If there is no clear frame at creation time (say for a wiggly 3d curve), how do you imagine it being better to assign it only when it is asked for? As far as I can tell, that just makes object frames unpredictable.

Said another way, I don’t see any benefit to using lazy evaluation to assign the frame. Is it a computationally heavy or large piece of data?

Brian Gillespie

1 Like

Nothing really constructive to add, but this would be super super helpful!

I would even go so far as to say having a new Plane object (point at center, grips for X and Y axes) would make many things way easier, if even just to make creating and adjusting planes for Grasshopper quicker, easier, and more intuitive.

This would be so useful!! Maybe You could look at SketchUP’s components - they have own coordinate system that the user can change and orient so one can get appropriate bounding box sizes and cut list even for curved objects.

That would indeed be useful. I’ve previously used Text objects as a workaround (as these have both a plane and a handy method for inputting string values on the Rhino side).

This thread started 2 years ago.
I’m curious to know if this idea is still alive or if it has been abandoned … ( I hope not )

I really like both the per-object frame and the plane object !

I’ve been asking for these abstract objects (coord systems, planes, directions, etc …) since Rhino 1.1 …:older_man:
It would be cool if something like that would appear in Rhino 6. :slight_smile:


I think that objects in Rhino have frames associated with them now - but I don’t think there’s anything in the UI to make use of them yet. @andy can you please confirm?

I would also find that useful for many reasons. Last time I checked with Dale it looked like a frame is created once Gumball is ON for an object, and not by default…


@brian - no, that is not a the case.