[Radiance-general] Slow spawning of rtrace -n, mkillum -n with many light sources

[Greg Ward]

Hi Axel,

Thanks for sending me your model off-list.  Indeed, it is the source obstructor cache initialization that is taking up most of the start-up time.  It's tracing about 8.5 million rays, which would normally be done in about 10 minutes, but seems to be taking longer due to the preponderance of triangle mesh geometry in your model.

The Radiance triangle mesh (.rtm) format was designed to handle complex geometry in the smallest possible memory footprint.  To achieve this, I had to compromise a little on execution time.  In addition to the ray vector transformations that are also required by the "instance" primitive, tracing rays into a triangle mesh is maybe twice as expensive as rendering straight geometry.  If simple geometry is stored in a mesh, then you are paying this price unnecessarily.

To reduce start-up time, I would recommend putting the geometry into octree instances rather than triangle meshes if it's not too complicated, or just use xform if you aren't making multiple copies of the geometry throughout your model.  Having a single instance is wasteful of resources and costs overhead during rendering.

Another thing that will speed up the initialization is to use a frozen octree.  Your 7000 light sources mean 7000 calls to the shell to run xform, and there's no reason to do that except the first time, during octree creation.

Cheers,
-Greg

P.S.  More information on mesh primitive from 2003 workshop:  http://www.radiance-online.org/community/workshops/2003-berkeley/presentations/Ward/Tutorial1.html
Download the PowerPoint tutorial and skip to Section II around slide 42.

> From: Giulio Antonutto <geotrupes at me.com>
> Date: February 20, 2017 11:49:45 AM PST
> 
> a good trick from fellow friend colleague Francesco Anselmo is to use glow with a specific distance so only light close enough get cached… use with caution as it is a simplified calculation, but faster.
> G.
> 
>> On 20 Feb 2017, at 18:00, Greg Ward <gregoryjward at gmail.com> wrote:
>> 
>> Oh, I just remembered -- there's also the shadow cache, which gets initialized in marksources() as well.  This also ends up tracing some number of rays, about 400 per source, to look for near-source obstructions before the main calculation begins.  So, that could be part of your slow-down.  I guess 6,000 light sources would be about 2.5 million rays to trace, though I have trouble seeing how that would take 45 minutes even on one process.  It should only take a couple of minutes on a modern processor with enough memory to hold the scene.
>> 
>> You could try recompiling with -DSHADCACHE=0, but I don't think you would want to, as the shadow cache is the thing that really saves you with so many light sources.  I'd only do it to determine if that's what slows down the start-up.  (Although it would be an interesting test of the shadow cache under extreme conditions.)
>> 
>> I don't know how to sample running processes on your system, but it would be interesting to find out where rtrace is spending all its time during start-up....
>> 
>> Cheers,
>> -Greg
>> 
>> P.S.  More info on shadow cache in 2004 workshop program:	http://www.radiance-online.org/community/workshops/2004-fribourg/Ward_talk.pdf
>> 
>>> From: Axel Jacobs <jacobs.axel at gmail.com>
>>> Date: February 20, 2017 9:28:36 AM PST
>>> 
>>> Thanks for your answer, Greg.
>>> 
>>> There are no mirror or prism surfaces in this scene.  Just glass and
>>> plastic.  So this is weird, then.
>>> 
>>> I did notice this behaviour on previous projects where we had
>>> thousands of light sources, but didn't look into it back then.
>>> 
>>> Cheers
>>> 
>>> Axel
>>> 
>>> 
>>> On 20 February 2017 at 17:18, Greg Ward <gregoryjward at gmail.com> wrote:
>>>> Hi Axel,
>>>> 
>>>> There is quite a bit of initialization code, the goal of which is to get as much common data into shared memory as possible before calling fork().  This reduces the memory footprint of your processes, as well as avoiding redundant work that wouldn't make it go faster, anyway.
>>>> 
>>>> Included in this preamble are initializing the photon maps (if any), loading the octree, marking light sources (including virtual sources), and preloading the ambient cache (if one).  It also preloads all object data, including instanced octrees, meshes, pictures used in patterns, and so on.
>>>> 
>>>> Even with 6,000 light soruce, marking light sources shouldn't take all that long, *unless* you have "mirror" or "prism" surfaces in your scene.  These will create virtual light sources, multiplying the number of sources potentially by many times.  (Mirror surfaces that face each other are the worst case.)  The virtual light source preamble can take quite some time in such cases, as it tries to eliminate virtual source paths that would never pass light due to obstructions, etc.
>>>> 
>>>> If you don't have any mirror or prism surfaces, then I'm not sure why it would be taking so long.
>>>> 
>>>> Cheers,
>>>> -Greg
>>>> 
>>>>> From: Axel Jacobs <jacobs.axel at gmail.com>
>>>>> Date: February 20, 2017 4:01:33 AM PST
>>>>> 
>>>>> Dear list,
>>>>> 
>>>>> I'm running some rtrace -n xx calculations, and noticed that there is
>>>>> only one thread for 30 to 45 minutes, before the -n xx kicks in.  My
>>>>> scene contains some 6,000 artificial light sources.
>>>>> 
>>>>> The question I have is this:  Is there something within rtrace/mkillum
>>>>> that is not multi-threaded that is run before the actual ray tracing
>>>>> part starts (which does honour the -n option)?  I could think of some
>>>>> light source visibility or intensity test that need to be done before
>>>>> the actual ray tracing.
>>>>> 
>>>>> Many thanks for your thoughts
>>>>> 
>>>>> Best regards
>>>>> 
>>>>> Axel