The thing just seems to fail with the most basic task:
Draw a line.
Extrude said line in z axis.
Extrude surface along normal with gumball.
Move box along normal. (the gumball aligns completely wrong, no longer perpendicular to the box).
Took us 2024 years to get here. Bravo.
Not sure but I can think of a couple of reasons why you might see this behaviour -
For starters, is your original line ortho in relation to the cplane?
Alternatively - itâs difficult to tell from your screenshot but are you sure the gumball is no longer perpendicular to the box in the final screenshot? It looks close to perpendicular, centred on the volumetric centre of the selected objectâŚ?
Do we care why? The behavior wrong no matter what. Wrong as in not expected, not coherent and not useful for the end user.
If you are curious, I think Rhino has always struggled with aligning to polysurfaces, regardless of whether they are boxes or not.
It is a random planar line.
Yes I am sure. Just try the steps yourself.
So in your last image the gumball may be aligned to the cplane. If the object isnât in ortho this means that the gumball wonât be perpendicular in relation to the object.
I donât know how familiar you are with Rhino and/or gumball functionality so apologies if Iâm teaching grandma to suck eggs or missing something here -
But have you tried âalign to objectâ in the gumball menu (the white bubble attached to the gumball)?
Or try reorienting the cplane using cplane>3point or cplane>object?
It is set to âaligned to Objectâ 
I joined this forum in 2015 while you did in 2021 according to your profile. I am pretty familiar.
Thanks for the kind intentions but I know what I am talking about, just let someone from McNeel answer.
To be clear I would like this to be regarded as a WISH to correct the Gumballâs behaviour.
ok Iâll stop trying to solve this.
But fwiw Iâve also never found the âalign to objectâ gumball option works reliably except with very simple 2D geometry.
I find manipulating the cplane a more reliable way to model âoff orthoâ. Or rely on the ortho geometry of the cuboid itself with extrudesrf etc.
100% there are some alignment issues with the Gumball. When I do what youâre doing I basically get a similar result. When it doesnât align is proper broken, that is, you canât toggle back and forth between CPlane/Object alignment and have it reset. In fact I think the reset doesnât even work. One work-around is to align the CPlane to the object (you might have to create an object to align it to) and then just align Gumball to CPlane. This will always work but itâs extra steps. You can also manually re-position the gumball but again this is extra steps. The CPlane/Object is my go-to for now.
I repeated a similar issue. The picture below is âaligned to objectâ. If anyone still things this is âparallelâ or aligned I want to know what drugs theyâre taking and where to buy them. There was other stuff going on such as the Gumball being at the bottom-left of the plane after extruding the line. Itâs turning into a bit of a crap-shoot actually.
Yeah, have had issues like these for a good while now where gumball out of nowhere decides to re-orient itself in some weird way and mix up all the axes, or locate itself far away from the selected object.
I made a post on this too a while back and have seen others suffering from the same problem. But I havenât heard a word from the devs on this. If they could at least confirm that they know the bug exists and are (hopefully) working hard on it.
This is such an annoying issue, I have to constantly âreset gumballâ when working in R8
The example I mention in this post does not get fixed with resetting, just clarifying that.
Again not solving the issue youâre raising but in terms of optimising a workaround/alternative approach -
You could set up a macro or hotkey for cplane>object.
Niko Dellic hammers out this approach here - https://youtu.be/-Zl_2aXwdjU?si=AF2ardhgWv7GiSgG
I think this workflow has been set up more or less as standard in R8 as part of the âuse Rhino like Sketchupâ push-pull modelling approachâŚ? Still in R7 myself.
The issues might be exclusive to R8. I donât recall having some of these issues in R7. But my workflow(s) have evolved a lot recently.
Thereâs lots of issues with R8 but lots of good things too. Itâs becoming a matter of whether or not you can work around the flaws. I had R7 sorted out and was happy with it, but its hard to go back after experiencing R8.
Same.
Hi @ShynnSup
Rhino is horrible at this but I must say that I have yet to use a program that really gets this right.
In Blender and in Unreal I run into much of the same thing. But I have to say Rhino really gets it wrong almost all the time and on simple box shapes this shouldnât be so hard to figure out.
I just ran into this where the only way to really set a gumball properly was to create a cplane that was oriented correctly and then use gumball align to cplane. For 90 percent of the time align to object never works even on boxed shapes.
RM
There are loads of great features in Rhino 8.
Gumball is a nightmare. It has random failures to align, it often fails to even align to something highly planar, it forgets its alignment, invents new axes, shifts super far away from the object randomly⌠Yep, reset often fails. Gumball cycling often doesnât make sense.
it has been reported already quite a while ago, but nobody from the staff could ever reproduce it other than the frantic users here trying to report and get ignored⌠idk
yeh Gumball does random things in V8 compared to V7, all mentioned above
Help me understand whatâs going on here. In the picture it looks like the scale handles touch three of the faces and the arrows are parallel to the edges of the boxes. In this case it looks like a decent fit. If the extruded line isnât parallel to the CPlane X or Y it can be a bad fit. We could detect and orient to boxes but thatâs only going to fix this situation.
Orienting the gumball intelligently to an arbitrary polysurface is not easy. I donât think weâve dramatically changed how the gumball chooses its default orientation for Rhino 8. We certainly can improve what weâre doing now but what is coherent and useful to you? Is the major issue poor default object alignment for you? Are the other alignment modes fine?
I know the bug exists. I havenât been able to reproduce it and as far as I know none of the tech support has been able to dig up reproducible steps. Random is hard to track down. Iâll keep digging into it. The gumball orientation is saved on the object. For 8.9 I fixed up a lot of those random jumps with this bug where that orientation was being copied from old to new objects. In 8.10 we scaled back how often we save the gumball orientation to hopefully relieve some of this as well here.
If you compare both pictures you can see how the normal of the surface is slightly different than the x axis of the box. Which makes no sense because they are geometrically equal. I noticed this because when I moved my box to perform a boolean operation, the result was slight off and I had no idea what I had done wrong. I was lucky to notice the error because it was so minute and would have been a pain to fix later on.
This is indeed what is going on, the line is almost parallel to Cplane, rotate about 3 degrees or so.
The big issues for me is that the user assumes the gumball will behave the same for a planar face than for the resulting box of extruding this planar face, and in this particular case, risk never noticing he is actually moving in the wrong direction by some millimeters.
I would really like gumball to be a little more reliable and practical in simple scenarios like this, specially working with orthogonal geometries. A box is not an arbitrary polysurface.
I find it disappointing and cumbersome that to move a box along one of its axis, I need to either Move>Click one point alog one edge, and decide a distance.
Align guball to plane>turn on AutoCplane,>select one face of the box>select the box>move with gumball along correct direction.
I have a dream where I select a prism and the gumball perfectly aligns to its faces and I can scale, move and rotate with the gumball withouth any additional work.
Let me add, extruding any planar curve in one of the main axis, such as extruding a rectangle in +Z to make a wall or extrude a random blob laterally, to give it width, Gumball should keep its orientation unchanged. You are just adding width to a curve or surface.
Example 01: Extrude 2d curve +Z
This is the same object just running basic functions to it. (Gumball set to Object).
Example 02: Extrude 2d curve normal to curve.
These 3 shapes should have the same gumball all the time. And when the three are selected you get a gumball at center of mass.
You can see wrong orientation to what it seems obvious to human eye what should happen.
Example 03: Subd cylinder rotated along Y axis.
Gumball does not align to obvious ring selection.
Well to make thisâŚ
Basic stuff as scaling a circle/polygon uniformly along its construction plane.
rotated subd.3dm (93.7 KB)
Iâm still a bit lost. If the gumball is in object mode, you extrude a line, then select that surface and extrude it, you get a nice box with only right angles. When that box is selected though the gumball will be off since the gumball just sets itself around the objects bounding box. As far as I know this has always been the case except for planar things. I opened an issue to improve this here since I couldnât find and existing one. This should cover example one as well.
Iâm not convinced about this one. The gumball is at the curve start since getting the curve center only makes sense for really simple closed curves. A smarter orientation like the attached issue above might help with this. The second part I believe weâre aligning to the surface U direction here but I may be mistaken. And the third part is again just a bad bounding box fit.
This is still the bounding box issue. The gumball always orients to the selection bounding box for selections of multiple things. I have an open issue here which is essentially for multiple selections if they are coplanar then align to the common plane in object mode. I added a note to the issue.
It seems to me like the big problem is making the gumball smarter in object mode. I completely agree itâs bad but I think itâs going to be a significant amount of work to fix.
my answer:
please see this post:
and please - expose it to rhinocommon, so we can add custom gumball orientation hacks.
