genBSDF -n option doubt

Dear list;

I have been using the genBSDF a lot lately, and just today I decided to use
both cores of my computer. Long story short, I tried the "-n" option
directly on genBSDF, on the "r" options alone, in the "r" options with
ambient file; nevertheless, I got my best results using just one core.

What is correct (optimal) way of using parallel processing in genBSDF?

THANKS VERY MUCH

German

Hi Germán,

It should be fastest using the genBSDF -n option directly, rather than putting it in your -r option list. Using the latest version of genBSDF from the HEAD, the -n option generally works pretty well in my experience. In cases where the geometry and light interactions are very simple, there may not be much gain as the calculation is constrained by file i/o operations. This is particularly true under Windows, which are forced to use ASCII rather than binary files due to the ages-old lack of any sensible end-of-file detection on that system.

Cheers,
-Greg

···

From: Germán Molina Larrain <[email protected]>
Date: January 30, 2013 1:51:46 PM PST

Dear list;

I have been using the genBSDF a lot lately, and just today I decided to use both cores of my computer. Long story short, I tried the "-n" option directly on genBSDF, on the "r" options alone, in the "r" options with ambient file; nevertheless, I got my best results using just one core.

What is correct (optimal) way of using parallel processing in genBSDF?

THANKS VERY MUCH

German

Thanks Greg!

Well, maybe I will see a difference when trying more complex geometries. I
am using the official Mac LBNL release (could not compile the Head one);
just for you to know.

In the other hand; I am trying to see the difference between the BSDF
generated when modeling a glazing using the "glass" primitive given by
Optics; and the BRTDfunc given by the same program. For now everything
suggest that the second one will need much more rays to converge... am I
right?

I am expecting to see difference in the reflecting part, not in the
transmitted part.

THANKS VERY MUCH

German

···

2013/1/30 Greg Ward <[email protected]>

Hi Germán,

It should be fastest using the genBSDF -n option directly, rather than
putting it in your -r option list. Using the latest version of genBSDF
from the HEAD, the -n option generally works pretty well in my experience.
In cases where the geometry and light interactions are very simple, there
may not be much gain as the calculation is constrained by file i/o
operations. This is particularly true under Windows, which are forced to
use ASCII rather than binary files due to the ages-old lack of any sensible
end-of-file detection on that system.

Cheers,
-Greg

*From: *Germán Molina Larrain <[email protected]>

*Date: *January 30, 2013 1:51:46 PM PST

*
*

Dear list;

I have been using the genBSDF a lot lately, and just today I decided to
use both cores of my computer. Long story short, I tried the "-n" option
directly on genBSDF, on the "r" options alone, in the "r" options with
ambient file; nevertheless, I got my best results using just one core.

What is correct (optimal) way of using parallel processing in genBSDF?

THANKS VERY MUCH

German

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

The HEAD should compile smoothly on the Mac, since that's what I'm using. There were a number of bugs fixed in genBSDF and related procedures since the official 4.1 release, and you really should be using the HEAD for that. Also, the -n option works much better in the latest code using the new rcontrib, although I expect you still won't see much of a boost for simple geometries.

If you use the Klems matrix to represent a BSDF, it won't resemble the output of Optics due to the spreading of the direct component in the former. You might do a little better with a tensor tree representation, but a BSDF data file will never live up to a material model when it comes to sharp peaks.

Cheers,
-Greg

···

From: Germán Molina Larrain <[email protected]>
Date: January 30, 2013 2:15:31 PM PST

Thanks Greg!

Well, maybe I will see a difference when trying more complex geometries. I am using the official Mac LBNL release (could not compile the Head one); just for you to know.

In the other hand; I am trying to see the difference between the BSDF generated when modeling a glazing using the "glass" primitive given by Optics; and the BRTDfunc given by the same program. For now everything suggest that the second one will need much more rays to converge... am I right?

I am expecting to see difference in the reflecting part, not in the transmitted part.

THANKS VERY MUCH

German

2013/1/30 Greg Ward <[email protected]>
Hi Germán,

It should be fastest using the genBSDF -n option directly, rather than putting it in your -r option list. Using the latest version of genBSDF from the HEAD, the -n option generally works pretty well in my experience. In cases where the geometry and light interactions are very simple, there may not be much gain as the calculation is constrained by file i/o operations. This is particularly true under Windows, which are forced to use ASCII rather than binary files due to the ages-old lack of any sensible end-of-file detection on that system.

Cheers,
-Greg

From: Germán Molina Larrain <[email protected]>
Date: January 30, 2013 1:51:46 PM PST

Dear list;

I have been using the genBSDF a lot lately, and just today I decided to use both cores of my computer. Long story short, I tried the "-n" option directly on genBSDF, on the "r" options alone, in the "r" options with ambient file; nevertheless, I got my best results using just one core.

What is correct (optimal) way of using parallel processing in genBSDF?

THANKS VERY MUCH

German

Hi German,

if you model clear glass, (almost) all transmission is direct. This works very efficient for the glass material type, but in theory requires infinite resolution for a BSDF if you want the models to match. I think there are not many cases where both the BRTDfunc and the glass model as given by Optics make sense, but Optics will not take the decision.

So for anything that you do not have any scatter defined, I'd use glass (dielectric if not thin and to be approximated as one surface).

BRTDfunc output is fine for anything scattering with the limitations of BRTDfunc in the ambient calculation. That is where Window6 comes into play, exporting the BSDF model which is really fully supported by Radiance - though it has a limited resolution.

Cheers, Lars.

···

In the other hand; I am trying to see the difference between the BSDF generated when modeling a glazing using the "glass" primitive given by Optics; and the BRTDfunc given by the same program. For now everything suggest that the second one will need much more rays to converge... am I right?

I am expecting to see difference in the reflecting part, not in the transmitted part.