often do i use the option vertical to hardconstrain the direction to move objects up and down. often do i forget that weirdly this option does not work in those cases. is that a mac bug or a general Rhino Bug?
yes there are alternatives, but hitting a quick v is just very convenient, why not allowing this to work here either?
Hello- V is relative to the active construction plane - in ortho views with the expected CPlanes, that means in and out of the screen, so to speak- is that what you mean?
-Pascal
hi, yes i thought so that this will be the answer, but from a user point that is not convenient, when the cplanes are set to standard which i usually use. maybe there could be a general world z according to which such commands could work, as option at least. maybe something like so?
Hello- In any case, for now, you can force WorldZ - or any direction that you need often - in a macro, if that helps.
! _Move _Pause _Pause _Along r0,0,0 rW0,0,1
-Pascal
dont see that as a critique, but why are you guys so dedicated to avoid implementing relieve, just because i can whirl spaghetti on my fork i dont have to eat it till i feel bad.
do you have all your macros at hand at every spot you sit at? all ways lead to rome. but i dont have to walk them all.
before i even start copying that macro i rather use alt (to avoid the snaps) then shift to hardconstrain the direction. but even that is a bit too much when just trying to get ahead with my work…
again dont see it as a critique, but i would love Rhino to be simple either, not just complex and full of complicated options.
Hello- this is the first time I’ve heard this request that I can recall, and since there are other ways to handle this, I hesitate to jump all over the request for an option, especially since World X and WorldY cannot be far behind and that starts to get pretty cluttery.
For now, I recommend putting this on a button or alias
Along r0,0,0 rw0,0,1
then you can constrain to that vector as needed.
-Pascal
hi again, well some things you can do in perspective, like using option vertical when moving, there this option makes sense? but when i have an orthogonal view then not. if that does not work then dont show the option, you just confuse people. and i am not a beginner but i still get caught trying.
other things you can not do in perspective and have to switch to orthogonal view like scaling 2d. like i mentioned here
it is just very inconsistent.
It sounds like you are running with only 1 viewport displaying.
With all 4, this is easy.
Use a command with the Vertical option in the Top or Perspective viewport, and you can see the Vertical effect in the Front and Right.
But, why do you say it does not work? -try it - ‘Vertical’ constrains normal to the current CPlane, that is its job . I’d say if that is not what is convenient for you at the moment you need a different constraint, hence my suggestions.
-Pascal
i am not able to see how that does anything usefull in an ortho. thats why i am asking maybe its a bug in Rhino for Mac? at least not how i would understand “vertical” when i press option vertical and complete the command the object remains where i started
thats why this is misleading, when i look at the screen i have a vertical and a horizontal, when vertical means actually normal to the current cplane which option vertical does nothing for in this view and forces me to switch to a different view while keeping in mind which axis i am at then i am getting chills and want to die rather than to work like that. sorry guys but either the wording is simply wrong or the function has to be implemented that it makes sense and while an option vertical would make sense in its literal meaning i see no way how the current layout is logic and completable without getting plenty of knots in the brain.
i suggest renaming it perpendicular/normal to cplane and/or change the function.
Try Move > Vertical > ‘click’ > 10 or -10. Pretty handy.
-Pascal
A general “given” in Rhino is inputs like X,Y,Z, Vertical, angles, etc. are all assumed to be CPlane inputs unless specifically overridden.
that is not handy when i have to switch to a different viewport to visually control what i am blindly doing in this viewport i initiated the option in.
here in my beautiful test scene with plenty of geometry i want to move the blue line to the height of the orange square (cube)
the only way is to use fiddly key strokes like alt shift then tab, switch viewport, or get bored writing macros after being led astray from the normal logical path of verticality. puh…
You can also use SmartTrack with Project on. (you can toggle those with aliases). In the case of your line, if it is truly horizontal, a ‘snappy drag’ with the gumball Y arrow will work too.
But I agree, it might be nice to be able to constrain moves to viewport X or Y. It’s relatively easily scriptable except for the dynamic preview, which requires more complicated coding (for me anyway) if you want to be able to preview the move of all the different object types.
These on aliases or f-keys, or buttons on the MMB pop up toolbar should work pretty well
Along r0,0,0 r0,1,0
Along r0,0,0 r1,0,0
etc, with or without the ‘W’
-Pascal
