|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Speeding up rendering many spheres
Date: 6 May 2020 15:06:58
Message: <5eb30ad2@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nicolas George
Subject: Re: Speeding up rendering many spheres
Date: 6 May 2020 15:21:54
Message: <5eb30e52@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|