Experiment: AutoCPlane mode as a V5 plug-in

oh. nice

can’t try it now but will do so later. so I’ll just run it as a python script and it stays active throughout the session? or what?

Yes, exactly it should stay active until run a second time (it’s a toggle) - you can hard code the path to an alias I suppose -

_-RunPythonScript "blah blah"

to make it more command-like. (easier to toggle on and off)

-Pascal

Yes Pascal, this was my first impression.
In my opinion, maybe it’s just me, it’s enough to have only the 3 main planes.
This way is easier to know were you are.

OK, that should be easy to test - I wonder if the color coding is still useful - light color when in the back of one of the three CPlanes, dark color when in front…? I find it helpful, I think, but still just testing not doing any real work.

-Pascal

Don’t know, but I don’t like too much color code in a cad.
There’s already the red, green, blue code for the X Y Z.
Maybe the what could change are the color of the axis, normal in front, dimmed in back.
Just a proposal.

Update that does not flicker. (Thanks Giulio!.. Scripters, use the Draw2dRectangle function for this, not DrawPolygon…)

AutoCPlane.rhp (18.5 KB)
KyleMode_NoViewSnap_Label.py (9.0 KB)

-Pascal

1 Like

hey pascal.

so, it’s buggy on (my) mac but it does appear to work properly once it gets going… within ten seconds of initiating the script, i get this:

(hmm… i guess i’d ruin the thread if i posted the message here… it’s real long.)

kyleModeErrorMac.txt (46.2 KB)

that’s with osx 10.10.0 and wenatchee dec02,2014…

it looks as if some of my system shortcuts may be affected right now (for instance, i use ⌘-space for spotlight/launching my textEdit app for placing the error message into and that appears broken now… i’ll reboot after sending this to see if kylemode has anything to do with it…


all that said, i get it that troubleshooting for mac isn’t high priority on this experimental functionality… i’ll test if you have new versions but no hurries/worries



[ADD] i rebooted and my spotlight shortcut works fine… ran a few other scripts in rhino then autoCPlane (got the long message again) then tried ⌘-space and it worked… so, false alarm on that part.

anyway, it does appear to work right for me… and yeah, something around 20 seems better, more natural…
i’m going to time machine this computer (haven’t gotten around to it yet :smiley_cat: ) first before i keep going with experimental code though.

Hmmm- yeah, looks like maybe Mac does not like my labels at all… not sure what is possible here, I just don’t have enough knowledge to troubleshoot this I’m afraid.

-Pascal

it’s fine… don’t sweat it

an immediate thing i noticed about the mode though… (all in perspective viewport)-- say you’re in something near a Front View so the cplane is vertical to world… when rotating around towards Right View, the cPlane goes to top then back up to vertical upon nearing Right view.

it seemed like the cplane should of stayed vertical throughout the rotation from front to right. (setting at 20)… like, it should of only switched from Front to Right at some point without the top plane intermission in the middle.

Yeah, that has been a bone of contention. Bob thought it was weird not to go back to Top when not in a clear ‘other’ plane. I had it as you describe initially. With small angles, I think it makes sense, or at least it feels OK to go back to Top, but with large angles, I am not sure it is better, I’ll fool around with it.

@piac made a cool variation that I am still messing with, which has the CPlane not change until mouse-up. I’ll probably post that version before too long to see how it flies.

-Pascal

i don’t know quite how to describe it but what i’m thinking is probably more how you had it set up initially.

if my setting is 20, then that should be the angle which determines what it takes to go from world to vertical… but the number should act like 45 (if i correctly understand how this is working) for switching from front to right…

or, the ground plane acts a little different than the rest of the planes… it shouldn’t be like a box with all sides being treated equally.

(again, i tried it for about 4 minutes total… so these are only initial thoughts)

you mean like–
i run _Line
click a start point on the regular cplane
mouse up then the cplane goes vertical
?
thats sounds awesome ; )

This looks like a bug that I need to fix on Mac Rhino; could you make a youtrack item for me @pascal? thanks

Thanks, Pascal !
I like it. I’ve been missing such a feature … and making buttons to quickly change the CPlane … :wink:

When there is no plane within the cut off angle, the World Top becomes active.

Hmmm … here is where it does not feel quite right to me…
I’d prefer the CPlane to stick until another plane enters the cut off angle.
Or maybe having a lock angle and a separate unlock angle, to be able to choose when to go back to World Top.
Adding a little inertia, so to speak …
Does that make sense ?

well, maybe it sounds awesome… i guess we’d just have to try it out first but i guess there are times when mouse Up doesn’t mean i want to change the cplane… i might just want to put the second point behind (from my viewing angle) the first point on the current cplane which would require to move the mouse up…

maybe viewing angle is the better determining factor here.


re: the error message… the problem with me testing right now is that the error is shown in the command history which normally pops up in the lower left corner when need be… so if i do anything, the history shows… but when that huge error message is in the history, my screen does this after every command :smile:

@stevebaer , I did not see the problem that Jeff saw, and I think that is sorted for him after a reboot. However, the labels do not draw at all on Rhino for Mac, that might be worth a bug report. OK, I see more errors from Jeff, I’ll test more on mac and make a bug item.

-Pascal

Yeah, that is what Jeff was saying as well. I’ll work on it a bit more and see if I can add settings to play with.

thanks,

-Pascal

Hehe - users are a real nightmare :grin: - never exactly two identical opinions…

Don’t you guys get that when you set the angle to 44 degrees? Then you will only land on the world CPlane in that narrow 2° window.

In my view, I’d use a small angle (somewhere between 10 and 20) and work in the regular world CPlane - just as before. It is only (in my experience, in my workflow) in rare occasions that I have to go to some plan & parallel view to construct something and then back to the perspective view.

Hi Wim.
… I don’t think so.
With 44 degrees, the cplane changes as soon as the view direction is closer than 44 degrees to World Top.
I’d like the cplane to stick until the view gets closer than, say, 10 degrees to World Top (or to another standard cplane)

You’re right about users opinions :wink:
That’s why I talked about a double angle setting: one angle to ‘grab’ the cplane and a different angle to leave it.
I think that that way more people might be happy … maybe … :smile:

if you set it to 44 then rotate from a front view to right view, it appears to flash… that’s no good… especially when something is in a trial phase and you have a chance to work out the little kinks like that…

regardless, even if it allowed us to enter 45 in which case the flash would be eliminated, that’s still too high a setting for triggering the the change from top cplane…

if there were two settings like:
horizontal 20 (if rotating the view from top to front, it waits til youre 20º from the ground plane to trigger)
vertical 45 (if you’re within 20º of the horizon, the cplane will never go to top cplane)

then it would feel better… but that’s going to be confusing to require 2 separate numbers. (1 number will already be confusing enough for a lot of users – or, not everyone will be interested in figuring out what that single number does… much less 2 numbers)


for me, i always want to stay in perspective when modeling… like-> always… and only use the orthographic views for drafting and 2D output… (well, i’ll often begin a model/shape in top view but once things start getting extruded etc, i prefer to stay in perspective)

the weird thing about rhino to me is that even if i’m looking at the model from the side and try to draw a line, it’s still sticking to the top cPlane where as (i feel) rhino should be able to recognize my perspective and see that it makes no sense to stick to the top cplane in this circumstance.

if this autoCplane mode can get working properly, it will be a good compromise between current rhino and something like Moi3D which does recognize a user may want to go vertical from cplane… it has a natural Z inference which is lacking in rhino. (for example, run _Polyline and try to draw a vertical rectangle in perspective… that process could go a lot smoother in rhino imo… i get it that there are other ways to draw a vertical rectangle… just for example though)

as in, while in perspective, you’ll be able to start a line, push shift key and draw a vertical line… which, to me, is better than using the vertical option in the commands (which all commands don’t have anyway) and it’s better than using elevator mode.

i guess ultimately, i’d rather not have the cplane moving at all and this kyleMode type abilities are more to do with the cursor & inferencing but this mode is a good start.
(well, that’s ignoring the fact that sometimes the autoCplane has good uses other than just trying to draw a vertical line easier… both options would be good)


but hey, just for comparison… download Moi (it has a free no-save trial) and draw the vertical rectangle with polyline in its perspective viewport… to me, that’s real sweet… you don’t even have to learn anything about the application or mod keys etc… it just does what you’re (i’m) thinking it should.

Huh … aren’t Rhino users able to run Revolve, or ExtrudeCrv Tapered ?
The angles might be command options with default values, so that you are not obliged to care about them.

Just my humble opinion, of course . :smiley: