Hi German,

You cannot access two different scenes/octrees from the same process, so no use 
in having different ambient files.
Again, it's a limitation in the design of the renderers and their use of global 
data structures.
You need to spawn separate processes if you want to render multiple scenes by 
calling fork() before you call ray_init().

-Greg

Sent from my iPad

> On Dec 12, 2017, at 8:10 AM, Germán Molina Larrain <[email protected]> 
> wrote:
> 
> Hello Greg, 
> 
> Well, yes... I want, for example, calculate the illuminance in a set of 
> sensors using two different skies.... something like:
> 
> # first process
> oconv scene.rad clear_sky.rad > clear.oct
> rtrace -af clear.amb $params clear.oct > clear.txt
> 
> # second process
> oconv scene.rad overcast.rad > overcast.oct
> rtrace -af overcast.amb $params overcast.oct > overcast.txt
> 
> The idea is to run both processes simoultaneously, internally in C++... I am 
> affraid that, when calling setambient() , the first process parameters are 
> modified.
> 
>     
>     // Expose the provided options
>     options->exposeOptions();
> 
>     // save the parameters
>     RAYPARAMS rp;
>     ray_save(&rp);
> 
> 
>     /* FIRST PROCESS */
> 
>     // set the ambient file
>     ambfile = &amb[0];    
> 
>     // set up Radiance
>     ray_init(&octname[0]);
> 
>     // RTRACE
>     for (size_t i = 0; i < nPoints; i++) {      
>         // calculate
>         rayorigin(&(*rays)[i], PRIMARY, NULL, NULL);
>     }
> 
> 
>     /* SECOND PROCESS... STARTS SLIGHTLY LATER THAN THE FIRST ONE */
> 
>     // set the ambient file
>     ambfile = &amb[0];    
> 
>     // set up Radiance
>     ray_init(&octname[0]);
> 
>     // RTRACE
>     for (size_t i = 0; i < nPoints; i++) {      
>         // calculate
>         rayorigin(&(*rays)[i], PRIMARY, NULL, NULL);
>     }
> 
> 
> Will the second ray_init call affect the rayorigin calls in the first process?
> 
> Best,
> 
> Germán
> 
> 2017-12-12 12:52 GMT-03:00 Gregory J. Ward <[email protected]>:
>> Hi Germán,
>> 
>> I don't really understand your question, even with the code snippet.
>> 
>> Multiple processes typically share indirect cached values via the ambient 
>> file (using a locking and update mechanism).  Therefore, it makes the most 
>> sense to use the same file name for all processes.  This has nothing to do, 
>> however, with the fact that "ambfile" is a global variable.  Multiprocessing 
>> in Radiance involves spawning Unix processes via fork(), at which point even 
>> global variables become local to each process.  There is no other mechanism 
>> for multiprocessing that is supported by the library, in part at least to 
>> the reliance on global variables.  All the memory is shared on a 
>> "copy-on-write" basis, meaning that an OS (like Unix) that can share memory 
>> across processes will do so to the extent possible.
>> 
>> What is it that you really want to do?  Do you want to have different 
>> ambient files for different processes?  There is nothing to stop you from 
>> doing this -- you just have to reset the ambient file with a call to 
>> setambient() after forking a new process.  The disadvantage of course is 
>> that processes will do a lot of duplicate calculation, and you will mostly 
>> negate the benefit of running multiple processes.
>> 
>> Cheers,
>> -Greg
>> 
>>> From: Germán Molina Larrain <[email protected]>
>>> Date: December 12, 2017 7:29:35 AM PST
>>> 
>>> Hello Greg and everyone else, 
>>> 
>>> I am working with the raycalls library (src/rt/raycalls.c file) in Radiance 
>>> in order to execute lighting simulation internally in a C++ program. I have 
>>> managed to trace rays (validation remains to be performed), and I have to 
>>> say that the library is pretty awesome. What I am doing is:
>>> 
>>> 
>>> However, I have one doubt: I would like to run several processes at the 
>>> same time, using ambient cache; but the char * ambfile is a global 
>>> variable, so I would need to use the same ambient file for all processes 
>>> (which is not what I want). How crazy is it to call  ray_init with a local 
>>> ambient file? Does that just destroy Radiance basic functioning? It already 
>>> uses a local octree... that is why I think could be possible. I was going 
>>> to try this myself, but I am affraid to mess with the core Radiance code; 
>>> so I'd rather ask first.
>>> 
>>> Best,
>>> 
>>> Germán
>>> _______________________________________________
>>> 
>> 
>> _______________________________________________
>> Radiance-dev mailing list
>> [email protected]
>> https://www.radiance-online.org/mailman/listinfo/radiance-dev
>> 
> 
> _______________________________________________
> Radiance-dev mailing list
> [email protected]
> https://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/radiance-dev

Reply via email to