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

[Axel Jacobs]

Dear all,

I thought I give a quick update on this.

Traditionally, we have been exporting our geometry to individual RTMs,
which is typically one per layer and material.  The project where I
first noticed this slow spawning behaviour with many artificial light
sources (around 7,000 in this case) had 40 individual RTMs, but on
some larger projects this can be several hundreds.

For each RTM, there is one rad file with only the mesh primitive in
it.  All those rad files are finally called from a master xform file,
as we call it.

Running this project (only -ab 0) took around 40 minutes with this
approach.  During almost all of this time, rtrace was only running as
a single thread, despite being called with -n 80.

Greg suggested that this approach is not ideal, and that it could be sped up by:
a) instead of RTM geometry (obj2mesh), use polygons (obj2rad)
b) expance all calls to xform in the master file (xform -e master.rad
> master2.rad)
c) compile a frozen octree (oconv -f master2.rad > test.oct)

I ran some test to find out which of the above has the biggest impact
on render times.  Expectedly(?), it is the use of polygon geometry
instead of RTMs that makes all the difference here.  Rendering time
went down from 40 mins to somewhere between 10 and 20 seconds.  It is
also a good idea to expand all xform calls, but once this is done,
using frozen octrees does not make the calculation significantly
faster.

Have a jolly good weekend, everyone

Axel



On 22 February 2017 at 09:55, Axel Jacobs <jacobs.axel at gmail.com> wrote:
> Hi Greg,
>
> thank you so much for solving this riddle.  I have to admit I have
> been blissfully unaware of the drawbacks of using RTMs. We use them as
> much as possible now, since I have come to appreciate the fast compile
> times and small octree sizes this can give us.  However, there have
> been quite a few projects where RTMs would take hours to compile,
> generating octrees many GB in size.  In such instances, we convert the
> OBJs into polygon, but without the normals.  Occasionally, we also
> need to go via obj2rad, simply because obj2mesh fails to generate the
> RTMs.
>
> Looks as if we need to take a fresh look at our workflow.
>
> Thank you for adding the limit on the source obstruction code.  I'll
> try this out in the next few days, and re-run the project
>
> Thanks again
>
> Axel
>
>
> On 20 February 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
>>
>> _______________________________________________
>> Radiance-general mailing list
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general