We’re actively working on all this stuff… and getting all of it to look and feel right takes time. Keep the feedback coming; I completely agree that we need Rhino to look and feel good by default. My guess is that none of this is going to feel better for many more weeks.
8 Likes
I have a suggestion about layer settings like material, linetype …etc
And when a layer selected we can see all child objects like in illustrator
Some of the comments in this thread seem to indicate there are aspects of the current UI which are very good. Evidently, whether intentional or not, rolling out the WIP UI with changes everywhere is showing up what those are in the community’s opinion.
Hopefully those aspects can be quickly recovered so the WIP doesn’t remain annoying to use for very long.
2 Likes
I have had the same issue with loosing of the state of the toolbars from the last session in V6 and V7 for quite some time. To this day I have no idea what was causing it but since I reinstalled the OS (W10) and installed V7SR18 the problem has disappeared completely. For me, the UI state would reset to default from time to time. And the only way to save it was to after setting it up again to my preference actually save the current Rhino model into a new file while it being the only Rhino instance running. Why? God knows. What you might wanna check is if the folder containing UI state is not set to read-only by the OS for whatever reason. Also, that your current user has the rights and permissions to write in that folder (that’s why run as admin was the cure for some people). One more reason could be a full disk and rhino simply has no space where to write the UI file. You also might wanna try to exclude McNeel and Rhino folders in your AV software from being real-time scanned/protected in Program files and AppData. Try one thing at a time and see if anything changes.
Best regards.
Thank you for the suggestions, but as far as I know none of those are causing the issue. I don’t use an AV software. I have plenty of space on my hard drive. I’m the Administrator of my PC. I removed and then installed a fresh new copy of Rhino 8 WIP - still causes issues with the state of the custom toolbars. No matter where I save the RUI file, the issue is still present. I tried with a new RUI file - still losing the state of toolbars. I run latest Nvidia graphics driver. Everything is up to date. Rhino 7 works flawlessly, but Rhino causes lots of troubles, including an unbearable 1-second lag upon each mouse click on a control point while trying to drag it.
if I have a say as to how I would like the new UI to be, it would go like this:
don’t change a thing, except for 
- the ability to make the scroll bars thinner
-the ability to make the command line dockable like any other toolbar, vertically and horizontally, top or bottom - refrain to emulate the Mac UI, it looks like the underlying drive behind the change is to make one UI for both platforms. I may be wrong.
In any case, thanx for the relentless striving to do better.
There is a major issue in the latest Rhino 8 WIP with wrong positioning of the Gumball after extruding a 4-sided surface (! _SrfPt) into a polusurface and then exploding the latter into separate surfaces. Instead of positioning itself in the very center of the new surfaces, the Gumball remains in the old place where the original extruded surface was located. The problem comes from the fact that upon selecting a non-horizontal ! _SrfPt surface the CPlane automatically orients itself to it’s center against any logic. Unselecting the ! _SrfPt surface brings the CPlane to its original location. That bug appears especially on non-horizontal ! _SrfPt. Horizontal ! _SrfPt seems to be fine.
Crazy Cplane reposition on SrfPt surfaces in Rhino 8 WIP.3dm (142.1 KB)
Try turning off Auto Cplane on the status bar. I don’t use gumball so I’m not sure that will solve the problem but it is worth a try.
Yes, that is the Auto CPlane. There’s even a help topic on it already
https://docs.mcneel.com/rhino/8/help/en-us/index.htm#commands/autoaligncplane.htm
You can disable it with the button on the status bar
What is the logic behind the decision to apply a LOCAL automatic Cplane to the non-horizontal surfaces only, whereas the horizontal ones are not treated in the same way?
Also, why extruded and then exploded output surfaces located far from the original surface (the one that was extruded truded) won’t receive a local Cplane subsequently (assumingthat the user wants use Auto Cplane), and instead the Gumball remains totally detached from them? This is counter-intuitive.
Hi Bobi -
As you show very clearly in your video, that statement is not true. It’s only for objects that are coplanar with the current CPlane that the Auto CPlane feature doesn’t move the CPlane.
I’m afraid I have no idea what this means.
-wim
My statement is true and clearly supported by the video I provided. Surfaces that are not co-planar to the current Cplane temporarily receive a local Cplane, whereas a selected co-planar surface won’t receive a local Cplane. The key word here is “local”.
As for the Gumball being improperly placed far away from the selected surface (which is an output from a previously exploded extrusion), I will show this in another video later.
The “horizontal” part of your statement in both of your previous posts was false. Your updated statement is true.
Initial testing showed that moving the current CPlane when that was coplanar with auto-CPlane would be more of a nuisance than it would do any good.
-wim
The default Cplane is horizontal, hence the default plane is also horizontal. This is all true in all of my statements.
Here is yet another example of something wrong happening with the latest Rhino 8 WIP related to the bug I reported yesterday. Note that “Single viewport mode” was not active! The ! _SrfPt tool works in a weird way, producing horizontal or vertical in a random fashion, and even twisted surfaces, despite keeping the viewport camera angle intact. This bug happens no matter if the “Auto Cplane” is active or not. I don’t think that this particular behaviour of the program is good, because it leads to heavy inaccuracy and misleading of the user as the default Cplane remains in its location all the time:
The ! _Box tool is also affected by this, refusing to build a large box while the mouse pointer is moved up or down. It works, however, when the mouse pointer is being moved sideways. Seems like an issue affected by the position of the mouse pointer relative to the initial point that started the creation of the object. Looks like Rhino 8 WIP tries to force the 2nd mouse click (the opposite corner of the base) to be vertical and will not let the user place it horizontally in two of the four possible directions:
P.S.: Processing of the videos by YouTube will take some time before they appear in 4K.
1 Like
You’re conflating two things. Another new option enabled by default is logged here:
https://mcneel.myjetbrains.com/youtrack/issue/RH-72108
When in ortho mode, as an experiment, we wanted to see about using the CPlane Z axis as a snap line. I was hoping to see if it made drawing vertically off the CPlane easier than elevator mode. Ortho mode atleast made sense as a place to put it. I added some drawing code yesterday to help inform the user as to what’s occurring. Unfortunately it’s not available in the current WIP. You can see it in a few gifs in the comments on the issue.
As for getting the old behavior back you can disable “Snap to CPlane Z” in the Ortho context menu.
2 Likes
In my opinion, that particular experimental behaviour should be turned off by default, because it causes a hugely disruptive conflict with the object creation and modification of existing objects, and will surely confuse the majority of Rhino users. It will basically not let the user build a box in two of the four possible directions. Even while the camera angle is nearly from the top, it’s impossible to build a box, which is counter-intuitive, because nobody needs to snap to the Z-axis from such a steep angle (maybe “snap to Cplane Z” should be disabled while the camera is raised so much, in a similar fashion as the “Single viewport mode”). Holding the Shift key to temporarily turn off the Ortho is not a solution to this new problem, because it will force a rectangular base for the box.
In case that you plan to implement it as a native feature in the final Rhino 8 program, my suggestion is to use a different colour for the visible vertical vector, so that it will be a clear indication for the temporary override to the default horizontal (i.e. Cplane co-planar) drawing/moving, which is typically rendered with black lines. Currently, the vertical snap vector is totally invisible. The user must be able to set a custom colour for the vertical vector, too. A mouse tooltip suggesting that snapping to the Z-axis is temporarily active also may help.
We’re gonna have to disagree on this. I agree the “Snap to CPlane Z” was a little undercooked when it went in the WIP, so I apologize for the confusion, but having it on by default gets it in front of eyes. This is the current UI with Ortho mode UI I’m experimenting with.
The hash marks are at the ortho angle snaps and the dotted line is the CPlane Z axis. I can add a note to the issue about the customizable color.
I found another bug in Rhino 8 WIP. It’s related to using 3d mouse from 3Dconnexion. When I activate the “Single viewport mode” (! _OneView) and rotate the camera to any angle other than the initial one, it will not update the changes on the changed active plane, and will also not update the marker at the upper right corner. That bug was also happening in Rhino 7.
However, there is another one. Any slight rotation of the camera via the right-mouse button after rotating it with the 3d mouse will result into an unwanted unlocking of the horizontal viewport manipulation and tild the view drastically. The horizontal view could be restored by rotating the view with the RMB again and then using the 3d mouse to do so.
Yes, having a visible vertical vector (the dotted lines in your screen-shot) as an indicator is way more usable than not seeing it entirely and having to guess if the program does something wrong.
On a side note, those 4 short horizontal lines should be used as a visual increment and correspond to the actual custom angle of the Ortho. For example, and Ortho of 45 degrees should have 8 of those short lines shown all the time around the point used to set the base of an object or while rotating an existing object. It’s a feature that was always missing in previous Rhino versions, but other CAD programs had it for years.
1 Like
That’s on the way. Here it is set with 45 degrees.
My only concern is it is a little bare bones currently. I’m half tempted to write the angle or maybe add some arc decorations around the tick marks, but I’m concerned that’ll clutter it. It’s based on the view size so it should always be visible.
1 Like