Box Edit & Gumball - further improvements


#1

Hello!
Box Edit and Gumball are already much better than in V5, yet how about adding this:

  • In the Box Edit panel, there are all these “Pivot Location” min/max dots. Why not simply use the Gumball location instead (or additionally)? Think about it - it’s just the next logical step, isn’t it.

  • In addition to the “Use World CPlane” and “Use current CPlane” options, there should be “Use Gumball”. It would make perfect sense to get/set coordinates relative to the Gumball, wouldn’t it.

I have a background with 3d programs like 3ds max, Softimage and Cinema 4D, and their “axis-oriented” way of manipulating objects.
Rhino I use since 2014, so I’m also quite familiar with the CAD approach of moving/rotating/scaling things via commands.
Both approaches are fine, and it’s cool that Rhino supports both - let’s just go all the way!
After all, the Gumball now seems to really stick to an object (very good), so it’s practically usable as it’s pivot/local coordinate system. What I’m talking about it doing it justice and ‘harmonize’ Box Edit and the Gumball as far as possible now.

Some more wishes:

  • The Box Edit panel should be able to display and edit Point coordinates, besides object coodinates (for now, the command EvaluatePt has to be used). Of course also when multiple points are selected - for that, it would also be very practical to have this “Use Gumball” option in Box Edit.

  • Pressing ENTER should immediately apply the changes made in Box Edit. Now, the APPLY button has to be clicked
    If the user wants to change multiple values before applying them, the TAB key could be used to jump to the next input filed (or the mouse of course).
    And if so, please see after that the TAB key jumps from X to Y to Z, and THEN to this new “uniform” checkbox…

  • That new “Uniform: X, Y, Z” feature shows your good will… ;p
    However, wouldn’t it be easier to simply take the coordinate input field that the user sets focus on as the reference? That would make this (fiddly) extra option obsolete.

Some years ago I made a similar post, and there have been numerous other related debates - allow me to give it another bump. The way it is now just feels unsatisfying and halfway there.

Thanks for considering!!
Best regards
Eugen


Confirm BoxEdit with Enter Key
(Pascal Golay) #2

Hi Eugen - I agree that some integration between Gumball and BoxEdit is at some level a ‘no brainer’ They seem like two different interfaces to the same basic idea. They are not now, as far as I know, talking to each other, but I bet that your first step of using the gumball location for BoxEdit is not out of the question, I’ll ask…

Look what I found:
https://mcneel.myjetbrains.com/youtrack/issue/RH-10223

-Pascal


#3

Good news, thanks!!
I don’t know why this bothers me so much… every time I look at the BoxEdit panel, it see big red letters reading “under construction”…


#4

For the sake of clarity (I hope), here’s the problem in other words:

Originally, Rhino objects did not have a Pivot (=object origin = center =local coord. system). They were just a list of coordinates in world space.

What BoxEdit still does every time is ‘analyze’ that coordinate list (which can be slow), and derive a ‘temporary’ pivot from it, depending on the ‘Pivot location’ options, so that it becomes possible to apply transformations relative to this Pivot.

Now, since there’s a Gumball that’s remembered with the object (for years now), this whole analyzation step is obsolete - the Gumball is already the Pivot!
The thing left to do is: modernize that BoxEdit panel… now is the time!

Just sayin’…
Just naggin’…

=}


#5

Makes a lot of sense!


#6

No, not really, it just uses the object’s world- or cplane-oriented bounding box (depending on the radio button checked), which is very quickly calculated. That is, incidentally why it’s called “BOX Edit”. The default pivot location, like gumball (except for the “to object” setting), is the center of the object’s bounding box.

–Mitch


#7

Ok, maybe the bounding box calculation is fast, and the bbox might be useful also for other things, so it shall be… (how generous of me! ; }

My point is,
BoxEdit should allow numerical inputs also in an object’s LOCAL space, besides WORLD or CPLANE.
Ok, you could set the CPlane to the object, (which can be a bit of a hassle) and set the transformation center in BoxEdit (restricted to min, max, center).
But why mess around when the Gumball already can represent an object’s local space and center?
Thus the wish for an additional GUMBALL=LOCAL mode in BoxEdit.

In fact, we can already numerically transform an object in local space - by clicking the Gumball’s axes and entering values. Consistently, the same should be possible in BoxEdit, where the practical SIZE parameters exist, too.

Btw.: the regular move, rotate and scale commands all correctly update the Gumball. Nice!
And: I just saw the CPlane command has an option ‘Gumball’… nice, too!

So, almost everything is in place… except a few BoxEdit options.

Anyway…
Best regards
Eugen


#8

Well again, this depends on all objects having an intrinsic center or pivot point that is part of the object definition that you can somehow act on. Which is not the case currently.

Now, if you reposition the gumball, it does remember its position between sessions - so this info is stored in the file somewhere, either on the object, or elsewhere - don’t know where actually. So, this info could be transferred to BoxEdit - so that if you modify the objects “center” using the gumball, that BoxEdit would also use that same new “center”. Probably need another checkbox in BoxEdit - something like “use Gumball center when available”. @pascal ?

–Mitch


#9

You say it yourself - the gumball (a matrix) IS stored with the object. What more to ask for.
Could work…


(Brian Gillespie) #10

RH-10223 is fixed in the latest WIP


#11

Really great, thanks a lot!! You guys are really open-minded!
I just tested it a little bit - seems to work.

However, here are a few more things regarding the Gumball:

  • in the Gumball-context-menu, the options “Align to CPlane/Object/World” sometimes don’t seem to work. Trying to narrow it down.

  • these “Align to …” options in the Gumball RMB menu and the BoxEdit options “Use world CPlane”/“Use current CPlane” - shouldn’t they be one and the same thing actually?

  • the Gumball has these Plane handles for XY, XZ, YZ. Which one of these Planes is visible depends on the viewing direction.
    Yet this view-dependet visibility is quite glitchy, or make no real sense.
    Softimage, for example, offers a better way to interact with the Axis(=Gumball). When I find the time, I will upload a screen video, but I believe someone already posted this.

  • Groups don’t remember their Gumball. Would be nice if they did!

Thanks!
Best regards
Eugen