On 5/6/20 2:05 PM, Nicolas George wrote:
> William F Pokorny , dans le message <5eb2e4cd$1@news.povray.org>, a
>   écrit :
>> Have you looked at bounding mode 2 (+bm2)? If not that's worth a shot.
> 
> I just tried with 20k spheres, it did not make a visible difference.
> 
...
> 

Ah, thanks for pounding home that you are using merge{}.

Try changing all merges to unions(1). Then perhaps +bm2 - for which 
there are a lot of tuning parameters I've played with only a little - 
might help. Just the merge to union probably more than enough speed up 
unless you're after real time rendering speeds or something.

Ignore my aside on the intersection depth issues (really a couple). Any 
real fix / improvement there is as likely to cost you time as not. If 
you're doing heavy AA though turning it off, rendering larger and 
scaling down 'might' be faster.

If you are using SDL to create those spheres, parsing could be a 
significant part of the total run time. Do you know how much time 
parsing and how much time rendering?

Somewhere I have some test cases with spheres. Let me see.... Yep. The 
one from the github comments.

-----------------------------------------------------
\time povr2 +w900 +h600 attractors.pov

2 million spheres in unions each with textures.

Parsing 17.325s / Bounding m1 3.504s

povr2 +w900 +h600
Render on my two core i3 : 33.781 seconds

Total CPU measured with \time : 136.43user 0:55.83elapsed
Memory about 1.5G

-------------

p380 (same as above,but many sphere intersections are dropped in v37/v38

107.96user 0.61system 0:45.06elapsed


Bill P.

(1) Unions unnest and so 'might' be better handled by the default 
bounding or +bm2.

Post a reply to this message

> If those spheres are not transparent, then, you need to replace that 
> merge with an union.

Before starting, I ran a few small tests and found that merge was slightly
faster. I suppose they were too small to be significant. Indeed, with the
full scene, union is incredibly faster than merge. I should have re-tested
earlier.

Thanks.

Post a reply to this message

geo### [at] phareinvalid (Nicolas George) wrote:
> I have a scene made of 200k spheres merged on a path (like a sphere_sweep,
> but with changing pigment and a ringed look), few are big, many are tiny and
> barely visible. Unsurprisingly, it is taking forever to render.
>
> I am looking for ways to speed it up.

Without knowing where your path came from, or quite what 'ringed look' means, my
suggestion might be useless to you, so apologies in advance!

However, in this situation I think I would seriously consider building this as a
mesh, creating a ring of triangles for each point of the path. Triangle rings
can be given different textures, either picked from a list (mesh2), or UV-mapped
from a gradient of your pigment 'space'. Parsing might still take some time, but
I would think rendering would be pretty fast.

Bill

Post a reply to this message