"clipka" <nomail@nomail> wrote in message 
news:web.49b84af5d4fd5b28801985dd0@news.povray.org...
> "[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.
>

Those are very interesting results, not all expected. Apparently, good 
programming concepts are not always good POV concepts... Unfortunately there 
appears to be a performance penalty for writing things extensibly using 
certian methods. :-(

At least this gives a clearer picture of how in any given circumstance to 
optimize for both reusability and efficient memory usage.

Do you (or anyone) have any ideas on how to perform an efficient inside() 
test on not just a single point, but an entire object? You can see the issue 
in my last image post, where even with an inside() test, the actual leaf 
objects occur partially within the cyl at certian points, even when the 
vector/normal reorient may not occur within the cyl.

At first glance it looks like a loop covering an array of vectors within 
min/max extent of whatever object A you are trying to determine may or may 
not occur within another object B is the only option (and then ditch 
creating the object at the vector which would produce such a coincident 
result), but that seems awfully crude. :-\

thanks!
ian

Post a reply to this message