POV-Ray : Newsgroups : povray.general : Speeding up rendering many spheres : Re: Speeding up rendering many spheres Server Time
23 Apr 2024 21:24:41 EDT (-0400)
  Re: Speeding up rendering many spheres  
From: Alain Martel
Date: 6 May 2020 14:54:38
Message: <5eb307ee$1@news.povray.org>
Le 2020-05-06 à 14:05, Nicolas George a écrit :
> 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.
> 
>> Related: There are issues in v37 and the official v38 branch - mitigated
>> 'somewhat' in my povr solver branch - with tiny sphere intersections
>> getting dropped when they should not be. Applies to a few other objects
>> too a situations too. Depends on exactly how the rays approach.
>>
>> This can affect Anti-Aliasing time somewhat substantially because the
>> spheres are basically blinking in and out of existence...  There is,
>> IIRC, some related discussion buried in the github pull req #358 comments.
>>
>> https://github.com/POV-Ray/povray/pull/358
> 
> I am using the version packages by Debian, they say it is a 3.7.0.8. Anyway,
> you tell me there is a problem with sphere intersections, but my scene only
> has merges, so I should be safe?
> 
> What I am really asking is:
> 
> merge {
>    A
>    B
> }
> 
> merge {
>    merge { A }
>    merge { B }
> }
> 
> where A and B are small and made of many tiny objects close together, but
> they are far apart from each other.

In that case, use:
union{
   merge{ A }
   merge{ B }
}

> 
> Will the second version be faster because POV-Ray will compute a bounding
> box for the two sub-merges, or shall I write:
> 
> merge {
>    merge { A bounded_by box_A }
>    merge { B bounded_by box_B }
> }

This will NOT help in any way.

> 
> ?
> 
> I shall test, but it would be helpful to know what is supposed to be the
> result.
> 
> Thanks for your help.
> 

Whenever you merge several primitives, they always share a single 
bounding box. Any ray entering that bounding box must test for 
everything it contains. ANY internal and manual bounding within that 
merge is totally ignored. That's why merge is so slow.

The purpose of merge is to suppress the internal surfaces when you have 
a transparent object.

So, if you don't use transparency, always use union, never merge.
If you have disconnected transparent components, use an union for them.



Alain


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.