After trying for a time to use more a viewport centric approach encouraged by H9, I'm beginning to wonder if there wouldn't be a better way to make use of the handles, as I find the current one difficult to use and confusing.

Example: I use the Shelf to create a Sphere. The sphere is placed, a handle is shown and at the top of the viewport I see it's parameters: Primitive type, Radius, Rows & Columns.
Having those parameters in view I logically assume that the handle shown is an “operator handle” and it controls those parameters.
It doesn't, and if I use it to change the proportions of my sphere it won't change the radius as I expect, instead it will change the scale at the object level (which is very bad, both generally and particularly to H9 which has a nasty bug regarding non-uniform scales).

I notice that in the top bar with the parameters for the sphere there is an arrow. If I press it it jumps me to SOP level. Apparently nothing changed, it's the same Sphere with the same manipulator and the same parameters at the top, but now the handle *does* change the parameters of the Sphere itself (the radius for example). Very easy to get lost.

My point: I'd like much more the “Y” handle to be an actual operator handle which let me access the parameters at the SOP level for the operator I'm working on and keeps my object transforms clean. I already have the transform manipulators if I need to transform.

If this isn't possible for various reasons, then at least it would be very nice to make it very clear what the handle is doing for each context and show the relevant parameters for that. Ideally, make possible to have both handles available and switchable from the handle menu.

Dragos

The idea of having the handle tool access the operator inside an object is very interesting. For now the handle tool is designed to let you go between different types of objects (lights, cameras, objects) and you get the appropriate “object-level” handle for each. Unfortunately the geometry object y handles are basically just translate/rotate/scale therefore they don't offer any special capabilities.

Another idea that has been floated around would be to have distinct looks for the object vs geometry level handles. That way as you navigate up and down there is some visual clue that something has changed.

The relationship between the object and geometry levels is one that inevitably requires some explanation. We have promoted some aspects of the geometry level up so that they don't get missed.

Robert

rmagee
Unfortunately the geometry object y handles are basically just translate/rotate/scale therefore they don't offer any special capabilities.

The problem is that when you see the parameters of the Primitive you just placed (Sphere for example) you make a mental connection and expect the handle to deal with those parameters (which actually happens when you're at the SOP level).
In the current form it makes it very easy to get lost or to create problems by mistake.

Another idea that has been floated around would be to have distinct looks for the object vs geometry level handles.

Sounds like a very good idea to me. It would be very useful to know if you're working at Object or “sub-object (SOPs)” level by the look of the handles. It's a detail which seems almost indispensable to me, for this new workflow.

Dragos

Another idea that has been floated around would be to have distinct looks for the object vs geometry level handles. That way as you navigate up and down there is some visual clue that something has changed.

Context colours? (Wolfwood adds: “and with no ramps, either”).

Cheers,

J.C.