Rhino 6 mac Beta

I think it is likely to do with the history of how and why the modes have been developed.

Others can explain better but the viewport mode that is called ‘rendered’ is rendered a bit like a computer game, ie the lighting is an unrealistic fudge and, I imagine, rendered by the GPU.

Using the render tool has traditionally used the rhino render engine which uses the CPU to calculate a higher quality image based more accurately on the lighting within the scene. I’m not sure what rendering technique has been used historically here but I don’t think it is raytraced. It appears to similar in some ways to the scanline renderer I used to use in another app years ago. This has always been far too slow to have as a live viewport display mode. It is also not as good as raytracing.

It is only fairly recently that raytracing could conceivably be performed in real time or near real-time. This, in theory should hopefully allow the two other tools / modes to be mothballed in due course which would remove the undeniable confusion that comes from there being two different images styles produced using tools called ‘render’ and a third by a tool called ‘raytrace’.

Now for hoping that raytrace mode and rendering speeds up a bit because the performance on my pretty new Mac is still really bad! I have to remember (this is vitally important) to not save and close a file with raytrace display mode activated. If I forget, the file takes FOREVER to load as Rhino prepares and starts rendering the raytraced view. So so painful.

ok…I just move “AsuniClasses.Common.rhp “LayerClasses” 0.1.0.0” and now works…great!!!

In the latest RhinoBETA, you can use TestToggleTechDisplayMode to turn on some recent optimizations that may - depending on your feedback - make their way into a subsequent service release. You can run the command again to turn it off. As always, please report any bugs you see.

Based on the test command name, these optimizations are specifically for technical, pen and artistic modes.

We do know that there are issues with this command and blocks right now. This should be fixed by next week.

On my machine (mid-2018 15" Pro with 560X) I notice improvements in performance and no change in visual quality in all three modes, particularly pen mode. It’s not the best, but it is much better. Thank you!

A post was split to a new topic: Merge Layers

I don’t use any of these except Blueprint which I believe is based off one of them (?)…

but yeah, the test command does improve this mode… without the TechMode test, there’s a slight delay prior to accelerating the navigation (using a trackpad which has a sort of acceleration/deceleration thing)

after running the test command, this little lag goes away…

also, if I TestMaxSpeed, I get nearly double the frame rate with TestTechDisplayMode toggled on…

(36FPS vs 20)


sorry, that’s all I got for this particular test :wink:

Don’t be sorry, that is great. Also, yes blueprint would be affected by this change. I’m hoping to get this feature turned on by default in the initial service release, but there is a bug with blocks I need to fix first as well as another optimization that will speed up the drawing of the intersection curves.

@stevebaer TestToggleTechDisplayMode:

not as spectacular as Jeff, but better: old vs new:
technical, pen, pen outline with the file posted earlier. Still in these modes this feels very laggy.

Also when rotating the viewport with the trackpad, when I give it a swing, there is a hickup after I release the trackpad. While swiping it kind of ok and after release also, but in between it stalls for a short moment.

Command: testmaxspeed

Time to regen viewport 100 times = 10.20 seconds. (9.81 FPS)
Time to regen viewport 100 times = 6.24 seconds. (16.02 FPS)
Time to regen viewport 100 times = 6.66 seconds. (15.03 FPS)

Time to regen viewport 100 times = 7.87 seconds. (12.71 FPS)
Time to regen viewport 100 times = 4.46 seconds. (22.42 FPS)
Time to regen viewport 100 times = 5.51 seconds. (18.16 FPS)

Those are still heading in the right direction. Results are going be very different from model to model right now as I still need to implement intersection wire drawing a different way. If the model has a significant number of intersections to draw, you won’t notice a big difference in performance.

Thank you for looking into this, it really does make a difference! :slight_smile:
My models do run quite a bit smoother now on outline views:

Old:
Time to regen viewport 100 times = 5.65 seconds. (17.71 FPS)
New:
Time to regen viewport 100 times = 3.20 seconds. (31.26 FPS)

With shadows activated:

Old:
Time to regen viewport 100 times = 14.59 seconds. (6.85 FPS)
New:
Time to regen viewport 100 times = 12.17 seconds. (8.22 FPS)

I’m mostly using outline view modes for presentations, so smooth navigation in the perspective view is my main concern at the moment.

I would really like it if I could open mac v5 and v6 beta at the same time.

Like this I always have to close the other and it is difficult to test the new versions while still working in v5.

Hello,

I’ve updated to the latest beta (Version 6 WIP (6.16.19197.13284, 2019-07-16)), Rhino became unusable. Existing or new model, doesn’t matter, even if I create a simple box, beach balling between the clicks all the time.:frowning:

Navigating also, I haven’t had issues before with shaded/wireframe, now it’s a disaster also, panning and rotating/zooming is useless - lagging and beachballing with each move.

MBP 2015 15" with 2,5GHz i7, 16GB RAM, AMD Radeon R9 M370X 2 GB (+Intel Iris Pro 1536 MB), macOS 10.14.5

Suggestions?

Thanks!

Can you please provide steps for reproducing this behavior? 6.16.19197.13284 is behaving just fine here. I suspect your preferences have somehow gotten broken. You might try resetting them to see if that changes things. Make sure to save a backup copy in case it doesn’t change things.

hi @dan,

that’s the thing:

  1. open RhinoWIP
  2. do anything

I’ve tried resetting the preferences, no luck there.
I will reinstall RhinoWIP and see what happens.

Did you ever install any plugins? That may also be a potential cause of this behavior

do Grasshopper’s plugins count?

Yes.
The components are installed in:

~/Library/Application Support/McNeel/Rhinoceros/MacPlugins/Grasshopper/Libraries/

(aka /Users/<you>/Library/Application Support/McNeel/Rhinoceros/MacPlugins/Grasshopper/Libraries/ )

Your Library ( ~/Library/ ) is hidden by default, so you might need to use the Finder > Go To Folder… and copy/paste the first path above.

This is the folder that you get to from Grasshopper if you go to File > Special Folders > Components

Yes, they count. Most likely they are not the problem, but it is good to eliminate them as a possible cause

For any Windows user following along this Mac topic, RH-53792 - Technical Display Performance improvements is also available in the latest Service Release Candidate for SR17 on Windows too.