Align to Object does not work.
To reproduce:
- Create a Box
- Rotate Box.
- Deselect Box.
- Reselect Box > Gumball orientation is wrong.
Align to Object does not work.
To reproduce:
not seeing this here on 8.1.23325.13001
tried rotating by the gumball, and also by using the rotate command
your screenshots look how mine behaves in gumball cplane node, though your status bar indicates object mode
Does not work with any combination (rotate with gumball or command, using Cplane or Object, etc)
Build is Rhino 8 SR0 2023-10-31 (Rhino 8, 8.0.23304.09001)
Hello- as far as I can see this behaves as in V7 - if you modify the gumball placement (for a single object) this is remembered, otherwise it uses the CPlane if set to use the CPlane.
-Pascal
Hi Pascal.
I am modifying a single object, by rotating it. I am not relocating the Gumball. Futher, Gumball placement is set to Object not Cplane. Still, you can clearly see how the Gumball is not aligned with the box.
Hello- it depernds on the object - if the box is an extrusion, then âby objectâ should works as you expect, however, objects that do not have an inherent plane do not remember unless the gumball placement on the object has been modified. If the box is a polysurface, there is no inherent plane and Gumby will not find an orientation to the object.
-Pascal
Yes the box is a polysurface.
Shouldnât Align to Object actually align to the object?
I see this working fine with a simple âIsPlanarâ Component in Grasshopper.
Can we agree on how cumbersome this is to work with, specially when rotating geometry?
It does when it can - there needs to be a plane in the object to align to - if there isnât then there is no info about how to align. So planar surfaces and curves can generate a plane, extrusions have a plane as part of the definition⌠oddly, spheres and surfaces of revolution ought to be able, I think, to generate a plane but it seems they do not. I bet that can be fixed. At any rate arbitrary breps do not have a plane⌠that is what you are running into.
-Pascal
I still donât get it sorry. I am not a developer nor an IT guy.
All I know is it works in other 3D suits, and I also know what an average user would expect. Specially a new user.
I also think I know what many users would like to see the Gumball actually doing.
This also has a huge number of implications for other kind of geometry and modelling, for example when it comes to control points alignment, extrusions and specially SubD editing.
In any case, I just created a Wish thread.
Edit: The GH example was to show how easily and fast (in computation terms) a CPlane can be constructed from an âArbitrary geometryâ in this case a box. Maybe Gumball can do that under the hood.
Could you potentially align to the uv frame at the reparametrized center (0.5,0.5) of the subsurface that was clicked on the selected object? Or even the uv frame of the point closest to the clicked location of the mouse? This would allow for objects without an inherent base plane to have at least a similar behavior in my mind.
Yes, something like this would be possible - I kind of hate to rely on pick location - my little test script finds the largest planar face, if any, and uses that, else you pick a face - it is clumsy but works. I guess ideally, for ambiguous cases a minimum bounding box function would be the fallback.
-Pascal
Is there something particularly bad with relying on pick location? I could see inconsistency being an issue, but that is a common with many rhino commands.
Have you tried a script that would use the uv frame at 0.5,0.5 of the sub face closest to the pic point? I suggested this specifically because I think this would have the most consistent behavior.
Well, it seems to me too apt to come up different every time you select, plus, if an object is window selected what do you do, and so on. I think it needs to be automatic and reasonably predictable. That is the hard part.
-Pascal
I think there might be a bug, or something else going on. The lower four form allowed me to align the Gumball to lower surface on the object before extruding, but not the subsequent ones which are increasingly curved. Thus I could extrude the first 4 only as Gumball will not align to the upper objects.
I think it needs to be automatic and reasonably predictable.
That wold be ideal, but a best-guess alignment would be better than none at all, or using the midpoint normal etc. Lots of ways of making reasonable guesses with user warnings, and R8 appears to be making some guesses for the lower 4 forms.
Gumball aligns to surface of lower 4
Gumball will not align to surface of upper forms
Youâll have to share the file so we can see whatâs happening with those surfaces
Hi Joshua,
Happy new year and thanks for your quick reply.
The file is attached.
For the 4 lower sweeping surfaces, after the lower surface of the left form is selected, Gumball can be aligned to the surface (and then extruded). Not so for the upper surfaces. The curvature increases for the upper parts, so perhaps that is a clue.
Thanks,
extrude.3dm (635 KB)
Thanks for providing the file. I had to do some digging but that looks like that alignment is by design. Currently for non planar faces the gumball aligns to the faces bounding box. Those faces are just barely not planar. I think with the Auto CPlane in Rhino 8 the CPlane orientation is pretty good for non planar stuff. Iâm going to try to wire the gumball up to use the same orientation. The issue is here.
Sounds good. R8 is fantastic in may ways, and I look forward to the few bugs being ironed out.
Could you also please remove my first name from the public post? Thanks.