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

Wed Mar 1 11:38:01 PST 2017

No worries, Axel.

Large models are a challenge, no matter what you do.  And it *can* be advantageous to use a Radiance triangle mesh for extremely complex geometry, even if it appears just once.  (Not true of octree instances, however.)  The intended use in such cases might be for a library object, such as a sculpture or highly detailed furnishing, which would be put in a mesh in a library.  Some objects like this from the CSAIL databased are provided in the Radiance library.

When obj2mesh fails, this can sometimes be remedied by changing the -r and/or -n options, but not always.

Cheers,
-Greg

> From: Axel Jacobs <jacobs.axel at gmail.com>
> Date: March 1, 2017 11:30:00 AM PST
> 
> Hi Greg,
> 
> On 01/03/17 18:34, Greg Ward wrote:
>> Hi Axel,
>> 
>> I thought you said that the actual obj2mesh call was taking forever,
> not the oconv operation afterwards. If it's oconv, this is due to having
> many overlapping volumes, which oconv attempts to resolve. If you didn't
> have so many RTM's (instanced octrees are also an issue), this would not
> be a problem.
>> 
> 
> Sorry about this misunderstanding.  obj2mesh is always very fast, but might fail.  What can take so long is the oconv compilation
> 
>> The rules of thumb on RTMs and instanced octrees is that if you
>> don't
> have multiple occurrences of something, don't use either. And if you do,
> then still avoid them unless you can packaged together at least 10,000
> surfaces or so per octree/RTM. Finally, it's best if your octree or RTM
> fills are more-or-less cubic volume, or is well-separated from other
> instanced volumes. Overlapping volumes cause issues for oconv.
>> 
> 
> This pretty much explains the issues we've been having occasionally. Thank you so much for clarifying.  What I thought your mesh presentations at the workshops over the last few years were telling me is that RTMs are always better due to the small octree size and fast oconv times.  Should have paid more attention to the small print, I guess.
> 
>> If I understood correctly the first time, and it is obj2mesh that is
> taking a long time, let me know which files to check out.
> 
> No, it's oconv.  Problem solved, I think.  Thank you so much for taking the time to look into this.
> 
> Cheers
> 
> Axel
> 
> 
>> Cheers,
>> -Greg
>> 
>>> From: Axel Jacobs <jacobs.axel at gmail.com>
>>> Date: March 1, 2017 2:36:30 AM PST
>>> 
>>> Hi Greg,
>>> 
>>> https://giauk.sharefile.com/d-s0cd3657a8b54fa9b
>>> 
>>> Here is the first scene.  This one does actually compile, but takes
>>> forever with RTMs.
>>> Compiling from obj2rad output takes just over a minute and creates an
>>> octree of 136MB.  Compiling from RTMs (with some polygon files) takes
>>> 200 minutes, resulting in an octree 37GB in size.  What we normally do
>>> in such a situation is to either reduce the number of RTMs to one per
>>> material, or to go via obj2rad.
>>> 
>>> I also noticed on a project I worked on a couple of years ago that the
>>> order in which the RTMs are listed in our master xform file matters.
>>> I was able back then to compile by listing the largest object
>>> (terrain) first.  Trying to replicating this behaviour today did not
>>> get the intended result.  The octree would compile either way.
>>> 
>>> So let me hunt down some more examples for you.
>>> 
>>> Let me know if you need the OBJs for your testing.
>>> 
>>> Cheers
>>> 
>>> Axel
>>> 
>>> 
>>> 
>>> On 22 February 2017 at 17:11, Axel Jacobs <jacobs.axel at gmail.com> wrote:
>>>> Hi Greg,
>>>> 
>>>> I'll ask around and find you some projects.  Give me a few days, and
>>>> I'll get back to you.
>>>> 
>>>> Cheers
>>>> 
>>>> Axel
>>>> 
>>>> 
>>>> On 22 February 2017 at 16:41, Greg Ward <gregoryjward at gmail.com> wrote:
>>>>> Hi Axel,
>>>>> 
>>>>> I'd be interested in looking at OBJ files where obj2mesh fails.
>>>>> 
>>>>> Cheers,
>>>>> -Greg
>>>>> 
>>>>>> From: Axel Jacobs <jacobs.axel at gmail.com>
>>>>>> Date: February 22, 2017 1:55:48 AM PST
>>>>>> 
>>>>>> 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
>>>>>>> 