The bounding box should keep its original plane instead of defaulting to the XY plane, which creates a rotated bounding box.
There is no way to keep information from a previous object? You know, like how primitives because in some other 3d software. So for Boxes, Rectangles, Circle, Cylinders, Spheres, etc you can run all sorts of transform operations but they will keep their starting Gizmo as they are primitives.
Sure, I did not suggest it was a new thing in Rhino 8.
It is just quite self-defeating that the Gumball canāt orient itself properly around a box to match its normals. And pretty useless too!
Yes, I get that:
Crv Start
Surface U
XY bounding Box
But, I still feel these three objects ought to have the same Gumball orientation. They are, in fact, the same shape. Why would I want a different orientation on the curve version than on the surface version? The priority should be the userās experience in manipulating these objects, not just the technical constraints of the tool. This is the kind of usability gap that development should address.
I have never had a practical use for the Gumball located at Crv Start. No only because of location but direction as well. You want most operations for Gumball to work as Bounding Box, that is, be able to rotate from center, scale from center, move from center, etc.
That would be great, yes. I wonder how software like Cinema 4D and Blender do it?
Thanks!
Nice to hear that you know of it at least. I completely understand that ārandomā is very hard to work with. Itās probably not random, just that I havenāt made a connection.
All that said, today I noticed I believe I now have the same issue as OP! Think I updated yesterday or so.
Push-pull & extrude seems to have been made with tiny angles, instead of 90Ā° normal. This ofc has made it all end up as a mess now where nothing seem to be straight.
You know, like how primitives because in some other 3d software. So for Boxes, Rectangles, Circle, Cylinders, Spheres, etc you can run all sorts of transform operations but they will keep their starting Gizmo as they are primitives.
Odd how Rhino puts the Object gizmo for box primitive off to the side. The cone shape seems fine. Whatās the reason for the box gumball not to be centered? (Both gumballs are set to Object)
There is no object transforms in Rhino attached to objects, other than to Blocks. In Blender and similar programs, mesh objects also have transform data, and traditionally this is because these packages are geared to animation.
I think we should have this at least for primitives. It is very handy for modelling. I have never done animation and I love this feature in those programs.
I was going to agree with you, but the more Iāve thought about it, the less inclined I am to agree this is an important feature.
Adding parametric transforms to all objects seems like it would be a useful feature, but when would you actually use it? Is it really good UX design to have two different ways of transforming an object when modelling? Itās useful in animation because you can attach the parameter to a keyframe and then tween between it. Iām struggling to find a time when I needed to do something like scale an object, but only wanted it to be temporary and reversible, and I couldnāt just duplicate the object and delete the duplicate when I was finished with it.
I do agree that having the gumball react in a useful way to primitives would be a nice touch, but I also almost never use primitives. Iām almost always lofting or extruding from construction lines so itās hard for me to expect any given polysurface that I make to have an objectively correct orientation. In the case of the example you started the thread with itās not strictly a primitive that you created, so how much overhead are you suggesting McNeel adds to every object in a Rhino file to make sure that any given object created through any means doesnāt happen to be a transform of any given primitive object?
Just look at the example above. It is about modelling. For instance, any person who uses SubD frequently has struggled with Gumball.
I guess making Gumball work with orthogonal geometry would be a start. You know, for massing, walls, and what not.
I also mentioned any planar curve being extruded.
I am not a developer or software savvy. I am just an user.
All I know is other software gumball works like a breeze and it is so useful there. But they donāt have everything else good Rhino has.
I hate when McNeel deposits their job on the users. Like āokay what do you suggest we do?ā
That is your job. I told you what I want and what does not work for me, think of something.
Whatās even more frustrating is when I offer potential solutions, even though itās not my job or area of expertiseālike suggesting primitives or object transformsāonly to be met with a barrage of excuses and irrelevant explanations.
All I know is that not being able to move a damn box with a gizmo along its normal direction is pretty stupid in my opinion. If that includes rewriting Rhino from scratch then we are doomed.
I can always just disable gumball given that I cannot trust it to help me model precisely.
I think getting these primitives right is the first step. Anything more complicated though will be challenging.
This is no longer true. In Rhino 8 we added the ObjectFrame. This is actually where the gumball stores its object mode orientation. When you relocate the gumball in object mode itās updating that frame. How it creates the default frame with the bounding box is poor.
Correct, extrusions have their own way of generating a default gumball orientation which I think is rarely useful.
Thanks for sharing this!! This might have other benefits as well. I think the extrusions are practically a legacy object intended to keep memory usage low.
Hi,
Maybe it has already been suggested but you have you already tried _GumballAlignment Object?
Personly I use GumballAlignment switching between Cplane and Object quite a lot.
I would say 50% of the time I want to move perpendicularly to the Cplane, and 50% of the time perpendicularly to the object.
Mapping these to your Keyboard (in rhino settings) makes this super easy to use.
Yeah, but this is a rather big issue with the gumball, because even if you relocate it to a custom orientation the way you want, any change to the object resets it which can be quite an annoying productivity paper cut.
Several years ago I proposed to develop a custom orientation of the Gumball, along with a quick toggle to switch between the custom orientation and the default one (or simply using the Gumball cycle order). The custom orientation is meant to stay always the same, no matter how much the object itās assigned to is being modified, rotated, moved etc. The only way to change the custom orientation is to set a new custom orientation to the object. That idea was not took seriously by the developers at the time, hence it was scrapped. I still believe that itās worth making it reality.
I think it is pretty clear in the original post. It is set in to Object Mode. Not sure what you mean by direction of my objects.
There is a line > Extrude line in Z > Extrude resulting surface normal (z) > Resulting box has wrong gumball which is not longer aligned to the box plane like so.
extrude normal relative to a particular surfaces normal while in object mode?
then move box normal of which of the six surfaces normals while in object mode?
can a poly-surface have one normal that the gumbal is expected to identify in object mode?
the user should expect the gumbal to be normal relative to a particular surface, then simultaneously be expected to have a correlative normal relativity to all six sides?
on one hand you have an object that is a constituent, and on the other hand you have an object that is the whole collection of constituents.
And pretty useless too!
