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

[Greg Ward]

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
>