Mesh swap is taking very long (threading)

[XilefTech]

So I got a rather large map that I am trying to render. When I now want to do the mesh-swap, it takes forever to complete. Even when trying to swap different block groups separately, it takes a very long time to complete. For example when I tried to swap the grass, it still wasn't finished after 2.5h.

When I looked at task manager, I could see that blender only used about 6% or 1-2 cores of my CPU. So now I was wondering why it wouldn't go faster and use more of my system resources. Is this process only single-threaded? If so, could you make it use more CPU-threads to make it more usable for large-scale applications?

[StandingPadAnimations]

Multithreading would be hard in MCprep for a few reasons:

• Python isn't really good with multithreading in general since it's limited to one process at a time due to the GIL(Larry Hastings made a good presentation at Pycon on the GIL)
• It wouldn't be good on all computers since most people have between 2 and 9 cores.

But the meshswap speed is unusual. If possible, perhaps try doing it in Cycles or EEVEE if you aren't already, and maybe uninstall and reinstall both MCprep and Blender

[XilefTech]

It wouldn't be good on all computers since most people have between 2 and 9 cores.

I don't see a problem there since you could make the thread-count adjustable. So you can render with only 1 core if you got a 2 core cpu and use 23 when having 24 threads available

[StandingPadAnimations]

Most Blender users don't know the number of cores they have, and it would make things harder than they should be(since a lot of MC animators are pretty young and just want to have fun). MCprep is open-sourced so you could always add It yourself

[TheDuckCow]

Hey there! Thanks for sharing your thoughts and initial ideas.Yes, mesh swap is very slow. Code-wise, the slowest issue actually has to do with duplicating mesh data for each instance (which sadly, wouldn't benefit that much from multi threaded, as those calls to blender need to be on the main thread otherwise we risk blender crashing). I did do an experiment years ago where I used a different method for duplication, using dupliverts. It would be a fair bit of a re-design, but would allow for significantly faster duplication, but at the loss of uniqueness fo applied modifiers per block. I'm not sure why the CPu would be so slow, but I have a feeling that it's more the operations to update/add new memory (due to the objects being added); Data access on the CPU is faster than RAM (and RAM is faster than Disk...). CPU reads to RAM take more cycles than accessing data on the CPU cache, and so a RAM loading/copying-bound operation may appear to be relatively idle in terms of CPU utilization, even if the total ram doesn't spike and there's just a lot of swaps occurring.

You can read / add more about this in the canonical duplivert feature requests. And as a not-so-subtle suggestion, it's a feature that would be open to contributions! If interested, I can flush out more of the ideas and different options/approaches for implementing there.