Extruding an open surface or polysurface results into self-intersecting output. I was able to freeze my Windows 10 twice that way, after extruding a simple open box (missing top surface). the majority of times it only freezes my PC for a few seconds, though. Extruding an open cylinder (missing top surface) or a revolved surface (car tyre) seems to be far quicker and won’t cause freezing to Rhino or Windows.
This one is related to “Snap to CPlane Z”. It makes it impossible to create a vertical curve along the ZX plane. No matter the camera orientation, Rhino 8 WIP prioritizes the ZY plane only.
I don’t see the lockup here, it has some delay but nothing too different from Rhino 7. In general Rhino takes little control over the sanity of input. That has a lot of benefits, but sometimes its downsides.
I’ll log the XZ thing for @Joshua_Kennedy to lookin to. Thanks
RH-72948 Wish: Creating vertical sketches on the XZ plane
Trying to extrude an open box causes severe slowdown on my PC for no obvious reason. This is the only object type that was able to crash my Windows 10. The interesting part is that any other object, including freeform complex surfaces and polysurfaces, won’t do that. The issue is present only upon extruding a basic 4-sided box.
In my opinion, the “Snap to CPlane Z” option should take the viewport angle into consideration.
The ! _OneView command would be helpful, but sadly it does not work at all while using a 3d mouse… It also does not work properly when camera rotation is done by the RMB. For example, this scene clearly shows that the view is almost parallel to the side wall of the box, however, “OneView” insists to keep the CPlane aligned to the bottom of the box.
In the state you’ve sent it, the default angle threshold of 10 degrees is not met. Here it switches when I change that angle to 11 or higher. The viewport needs to be refreshed to update the Cplane though, but the label in the upper right corner changes from ‘Top’ to ‘Right’.
The issue often happens even with angle set to 40-45 degrees, just like it’s shown in my screen-shot above.
But the main problem is the bug related to using a 3d mouse while “One view” is active. The label on the upper right corner updates properly while rotating the camera with 3d mouse, but the CPlane grid itself does not follow suit and instead remains at the latest state it was set while rotating the camera by the RMB of the regular mouse. The changing label is a clear indication that Rhino is able to detect the change of camera orientation done by the 3d mouse, however, something in the code is wrong, hence it will not trigger the actual change of CPlane despite what the label says (lack of viewport refresh maybe?). Hopefully that some fine tuning of the code will solve that huge problem for Rhino 7 and Rhino 8 WIP. I was a heavy user of OneView in the past, but I was forced to stop using it since it will not work properly with a 3d mouse.
My recommendation is to also enhance the label on the upper right corner this way:
Make a new option for the label to be also displayed in the cursor ToolTip (Rhino options > Modeling aids > Cursor ToolTip) called either “OneView” or “Single viewport mode”. This is where the user looks in the majority of time, much easier to notice the changes of the label than constantly looking at the upper right corner. Or, place the X/Y/Z letters directly on the CPlane grid so that they are clearly visible.
Add the CPlane X/Y/X letters to the label. Example: Top (XY), Right (ZY), Front (ZX) etc.
Add an option to choose whether the label will include the direction of the view only (Top, Bottom, Left, Right, Front or Back), the CPlane only (XY, ZY or ZX), or both (as shown in item 2 above).
You have to consider fixing the cursor ToolTip’s window as well, because the current implementation is extremely distracting due to its constant blinking caused by the different length of the numbers displayed inside that update multiple times per seconds. This is especially noticeable while working with a maxed out display precision (Rhino options > Units > Display precision).
A smart solution is to simply add about 300-500 milliseconds delay for the change of its size from long to short (but keep it instantly growing if needed). That way, the blinking will be eliminated in 99% of the time, because even if the currently displayed length of numbers decreases for a brief moment, the window itself will not follow suit instantly and will remain long for a brief moment, hence no blinking multiple times per second. As a person with sensitive vision that particular blinking is especially annoying to me. It will be even better if you manage to make that delay from long to short window adjustable in milliseconds, so that the user could set their own custom delay if needed.
Another bug related to the cursor ToolTip is the double rendering (ghosting) while drawing a curve, for example (or while drawing a box with the Shift key being held to force a square base). That particular ghosting is probably caused by slower rendering speed of the cursor ToolTip in those conditions compared to the faster update elsewhere.
Here is the bug with blinking cursor ToolTip in action, as well as the ghosting it produces while drawing a line. The video also shows the changing label on the upper right corner while the CPlane refuses to change accordingly. Note that the blinking experienced in Rhino is multiple times worse than what the video shows, because YouTube is trying to fix the blinking by adjusting the frame pacing and deleting some frames. The 4K/60 quality will be processed by YouTube in about 30 minutes, so maybe then it will show a more accurate representation of the blinking. When I open the same video locally in Media player classic in its original quality at 4K 60fps, the blinking is hugely distracting just like it appears on my screen while using Rhino:
@Rhino_Bulgaria I have come to appreciate the bug in OneView with a spacemouse. It gives you more flexibility. If you get to the point where the top right indicator flips to the view, you can bump the perspective camera with a short right mouse click and drag. Then you can leave it stuck on that view while you rotate out of that narrow 10 deg range.
It will be even better if you manage to make that delay from long to short window adjustable in milliseconds, so that the user could set their own custom delay if needed.