Are Display Meshes Generated by CPU or GPU?

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.

I completely disagree. Nay duplicated object doesn’t just ‘appear in the rhino file’, it’s the result of a duplicating command: Copy, option-drag gumball, copy>paste clipboard, or any ‘as copy’ option of a command. All Rhino’s arquitectura enreda to do is keep a table of object IDs of all the duplicates in a file at creating time. And as long as they do not get explored, modified geometrically (also easy to track) all those object IDs should be treated as instances.

It seems very easy to me, but what do I know? :crazy_face:

G

Yeah that’s history, what I said. And it’s so easy to break it would scarcely be of any use.

it would be nice if each brep face could be meshed on separate thread, but I imagine there would need to be some additional process on end to weld them somehow…

EDIT:
… or first preliminary division of faces edges, and later faces parallel meshing with constrained number of vertices on edges…

For example SpaceClaim already is doing something like that:

And it is very efficient.

Hello Andrew! Digging up this old thread - so I finally have my new machine up and running on a Ryzen 9 3900x 12 core/24 thread processor. I’m playing around using the test command with a large (~5 gig) file of OEM automotive data. I’m noticing that while meshes are being generated (this can take 5-10 minutes per layer on this file) that my CPU usage never really gets above 10%. So, it seems like there is a ton of resources that Rhino could be using, but is not. Is there a cap on how many threads Rhino will use (say 2 with the test command instead of 1?) or…maybe I’m doing something wrong?

-Sky

The test command won’t be of much use if there is only one object, or only one or two large objects, the rest very tiny (geometrically speaking: not much geometry data to mesh, resulting in simple, small mesh data).

Meshing of one object is still done in one thread.

Last layer I turned on for meshing had 878 polysurfaces, took about 30 minutes to mesh and CPU usage stayed at ~10% for the entire time.

On the plus side, with my GTX 3070 this thing rotates and zooms like a dream once meshed!

Perhaps you can share the file for further investigation using Rhino - Upload to Support - I have set myself as the recipient of the file, I should get notified when the upload has completed. It would be useful if you also copy and pasted the link to this discussion in the comments section for the upload.

Sure thing! It’ll take a bit to upload but I can share it.

-Sky

I did a test with both the multithreaded meshing disabled and enabled. I only have a 4-core i7-7700 (with threading that gives me 8 logical processors).

The first test withouit timing code in place showed me that with multithreading disabled there is indeed only ever the one thread active. With multithreading enabled I see sometimes around 90%.

Running now with some timing code in place to get some numbers. Without multithreading it was around 11-12 minutes IIRC, but will edit this post with the numbers I see.

From your original file I saved a version in Wireframe mode after running _ClearAllMeshes. The timing code also clears them, but since I am restarting and reloading the file it is a bit unnecessary. I also reset all my display mode settings so that Rhino is close to its default state.

Using the simple script:

import scriptcontext as sc
import Rhino as r
import time


r.RhinoApp.RunScript("_ClearAllMeshes", True)
r.RhinoApp.RunScript("ZEA", True)
start = time.time()
r.RhinoApp.RunScript("-_SetDisplayMode _Mode=_Rendered _Enter", True)
end = time.time()

print("meshing took", end-start, "seconds")

With TestEnableMultithreadedMeshing and disabled I get

('meshing took', 604.20027923583984, 'seconds')

with TestEnableMultithreadedMeshing and enabled I see sometimes high load from Rhino during the meshing with multiple threads:

It will all depend on how they all are scheduled and such. I am sure there is still speed to be had, but at least some improvement should be there. Interestingly though it took longer with multithreading enabled.

(‘meshing took’, 797.60556793212891, ‘seconds’)

I have logged this as RH-66359 Multithreaded meshing slower than single threaded

2 Likes