Are Display Meshes Generated by CPU or GPU?

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! :star_struck:

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 :man_shrugging:t2:

What error message?

Something like this


“error loading”…

the plugin toolbar works correctly in V8 wip but no more in V7

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

but that info would need to be stored somewhere otherwise there would need to ne an operation beforehand which would analyze for identical objects → extra time

I think it’s been established that no it has no way at all of knowing without history or the like. Maybe “machine learning” could do it? Otherwise it’s an insane thing to even attempt.