Best practice for decimating large number of parts with good performance?

Industry Unity Asset Transformer
,
1

Hi,

We have a need to reduce the amount of polygons for large Engineering assemblies

Just running decimate() on the list of all visible parts seems to do the job, and performance is good initally but then tapers off and the whole decimate process takes 45 minutes to finish which is way too long.

The parts are not under a single or few assemblies, we have excluded parts with high quality requirements such as cables from being simplified and they are spread out through the model, so today I use scene.getVisiblePartOccurrences() as the input to decimate(). Shrinkwrapping or heavily decimating the parts is not an option here, they must all be available for interaction but with a slightly lower polycount.

Is there any better approach to do this? Is there an option to work in the “Prototype domain” instead (16500 parts, with 4000 prototypes in this case)?

2

Me again!

Pixyz algos work on the “prototype domain” by default so nothing to optimize here.

Something to try before running decimation:

  • Identify and create even more instances using algo.convertSimilarPartOccurrencesToInstancesFast: this way other algorithms will run faster
  • Repair meshes using algo.repairMesh: might improve the quality of your meshes and make the decimation algorithm run faster

Also, check that you have enough RAM memory and that it is not swapping. This could slow down a lot your processes.

3

Some complementary best practice about decimation can be found here.

4

@PerryscopeVG - I’ve had a similar issues with extremely large models. Some of my scripts take 3-4 hours to process models (if it doesn’t crash) in Studio v2025+. The same models in v2022.1.2.7 process in minutes. Something significant has changed in the PiXYZ SDK algorithm that makes the later versions unusable for me.