I’m in the process of designing my next system to run Rhino. Sometimes I need to deal with large ~5 gig files, and it can be very helpful in that case to use the “Save Small” option and not include the display meshes in the save. The trade off of course is that I sometimes need to wait for quite some time for Rhino to generate the display meshes. Just curious - are the display meshes generated by the CPU or GPU? I’m betting CPU, but want to be sure. Thanks!
They’re CPU. I think GPU may be possible–well anything is possible, as in there have been tech demos, but that’s a future thing.
I’d actually like to see the not-save small option go away, I haven’t needed it in a decade, it’s a nuisance that the bloody meshes will still sneak in via a saveas or export sometimes. It’s time to look for features to cull like that.
2 Likes
I feel that! Maybe instead of having to check the box for save small, it should save small by default, and users are given a “save display meshes” option that by default is unchecked? Would be great as well if there was some way to utilize more of the system hardware - CPU or GPU - to create display meshes significantly faster. Typically I don’t care all that much about CPU for Rhino, really it doesn’t need all that much, but waiting for big meshes to generate is a bit of a time suck on occasion.
1 Like
There was a thread about dynamic GPU tessellation a while back: WISH: dynamic tessellation
to sum it up, it seams to be difficult to implement and there are other reasons for cpu tessellation beside performance.
2 Likes
Yeah…if I was to guess I think the idea of “GPU tessellation” will be skipped and eventually we’ll have some sort of “direct NURBS GPU rendering,” where whatever it does under the hood is invisible.
Sure, but it’s like, this is a feature that was arguably useful back in the 90s when, I dunno, I think the first computers I used Rhino on had between 100 and 200mhz? Though I think disk space was more precious than meshing time even then? (And I remember an early project where that could take 20 or 30 minutes!) Could we not just do away with it? I know someone will say no, but someone will say no to anything. And what other “features” are similarly obsolete?
Personally I’d say keep the option, but make it default to not saving them. Most folks don’t know about Save Small, but it should be the other way around imho. But, there are customers I have who use Rhino to review who are not tech savvy at all and would come back with “why does the model look jagged?” type of questions if left to their own on meshing.
CPU - writing a GPU based NURBS mesher would be a massive job and probably not really worth it.
Now…you didn’t hear this from me - but in recent versions of Rhino 7 there is a non-autocompleting command “TestEnableMultithreadedMeshing” type it at the command line at the start of a session…and let me know if you see significant improvements in meshing speed.
It’s not supported at the moment - if you see problems, just restart Rhino. But please let me know how it goes.
10 Likes
Wowwwwwwww! 
I’m on the latest version of 7 and I can’t seem to access that command - copied and pasted into the cl and it returns unknown command.
It works here…
Ditto here - cut the time in half on a very complex scene with lots of PBR/displaced materials.
-Jakob
Ahhh now it’s telling me an update is available…
1 Like
I tried and it runs. Unfortunately, after this test a plugin toolbar and a custom one disappeared and impossible to enable them again as it show an error message 
What error message?
For one polysurface made of 30 surfaces, totally 10’000 control points, render mesh with maximum angle 1.0 deg:
without "TestEnableMultithreadedMeshing” - 4.5s
with "TestEnableMultithreadedMeshing” - 5.0s
4 cores here.
And if you copy the polysurface 10 times?
For 10 of those polysurfaces:
without "TestEnableMultithreadedMeshing” - 60s
with "TestEnableMultithreadedMeshing” - 30s
with 4 cores
If they are 10 copies of the same polysurface, I would like Rhino to know that and take only 4.5 or 5 seconds. Not 30.
Shouldn’t Rhino know when an object is an exact replica or another object? Regardless of being a block or not?
1 Like