"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>   Finite objects:      1013230
> Peak memory used:        1414575125 bytes

I reckon your memory issues are not *per se* due to using a bucketload of CSG
instead of a few meshes.

I just did a quick test with 10k spheres, with a color-mapped pigment; the
following might give you some hints how to improve performance:

- With all spheres being generated on-the-fly as scene-level objects, I get a
peak mem of ~8 MB.

- If I #declare the material first, and use that in my spheres "as is" (no
translations, rotations or any modifications), peak mem reduces to ~6.5 MB.

- If I place the spheres in a union and attach the material only to the union,
peak mem reduces to ~3.6 MB.

- If I #declare the sphere first, and use translated copies, peak mem goes *UP*
again to ~6.4 MB!

- Worst thing I got so far was #declare the sphere first with a material, and
use translated copies, giving me ~12 MB!


Another thing I found was that first generating an array with object locations,
and then creating the objects in a separate pass, is more costly than creating
an array of objects right away.


Still, here's the best advice:


- If instead of generating 10000 spheres I #declare a mesh of 100 triangles,
then generate a union of 100 translated copies of it, I get a peak mem of lousy
~360 kB, which is just ~170 kB over my "baseline" peak mem. Even with 1000
copies, I still need just ~1.4 MB peak.

Given that you'll possibly need only one triangle per leaf to replace a pair of
cones (unless you want to do extreme close-ups - note that you can still
simulate curvature using a smooth triangle), this should be a good enough model
to give you a rough estimate of how much memory you can save.

Post a reply to this message