BSDF xml into Radiance

Hallo,

I manage to obtain bsdf in xml Format using Window7beta, but i couldn't
know how to insert it in radiance. Is there somewhere an example how to
embed or convert it into radiance material? I need to use it in dds.bash (
or rtcontrib).

Thanks in advance

···

--
*N.Nassif

Lighting Designer***
*PLDA Member

Neue Str. 55
21073, Hamburg
Deutschland

+49 162 6050060
[email protected]*

Hi Nasif,

Information for the BSDF material is at the bottom of page 12:
http://radsite.lbl.gov/radiance/refer/refman.pdf

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash is a
dynamic daylight simulation script). Putting the solar radiance into
skypatches relies on probabilistic sampling to find patches containing the
sun, and if you don't have much direct transmission from the direction of
the sun, you aren't likely to find the sun. Not finding the sun causes big
errors. For now, the three-phase method is a better alternative for annual
simulation of BSDF materials (you can find a tutorial at the bottom of this
page: http://www.radiance-online.org:82/learning/tutorials - if you're at
work, your company's firewall might block access to port 82 - the temporary
location of the new radiance online).

Andy

···

On Tue, Jun 12, 2012 at 8:18 AM, nassif nassif <[email protected]> wrote:

Hallo,

I manage to obtain bsdf in xml Format using Window7beta, but i couldn't
know how to insert it in radiance. Is there somewhere an example how to
embed or convert it into radiance material? I need to use it in dds.bash (
or rtcontrib).

Thanks in advance

--
*N.Nassif

Lighting Designer***
*PLDA Member

Neue Str. 55
21073, Hamburg
Deutschland

+49 162 6050060
[email protected]*

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

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly faster
then 2) as the fenestration system does not have to be traces internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

···

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

Hi Lars,

Andy probably is the right person to respond to this, but as he's on a vacation until the end of the month, I thought I'd offer a couple of comments (inline).

Cheers,
-Greg

From: "Lars O. Grobe" <[email protected]>
Date: July 25, 2012 1:18:42 AM PDT

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

More specifically, non-planar, specular reflectors run into trouble for insolation. Cloudy skies or sunless skies are no problem.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than #1, but the results are somewhat noisy. A new -c option to vwrays (coupled with the rtcontrib -c option) is a good way to reduce noise that is available in the latest HEAD. This is a better way to reduce noise than increasing -ad, and less costly.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly faster
than 2) as the fenestration system does not have to be traced internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

Andy has proposed an improved annual simulation method, which we hope to work on next year, to remedy the direct solar sampling difficulties in the 3-phase method. It should also alleviate problems with external facade geometry and reduce the need to subdivide windows.

···

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

Dear Greg,
   Thank you for letting us know about the -c option. I am going to try it with rtcontrib (sensors) and wanted to ask for advice on how to setup the points for averaging. For example, if I choose 4 for -c, do I send in the same point 4 times or is there a heuristic for perturbing or regularly spacing these points for improving results?
   Thanks for creating this feature!

- Dan

···

On 7/25/2012 10:44 AM, Greg Ward wrote:

Hi Lars,

Andy probably is the right person to respond to this, but as he's on a vacation until the end of the month, I thought I'd offer a couple of comments (inline).

Cheers,
-Greg

From: "Lars O. Grobe" <[email protected]>
Date: July 25, 2012 1:18:42 AM PDT

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

More specifically, non-planar, specular reflectors run into trouble for insolation. Cloudy skies or sunless skies are no problem.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than #1, but the results are somewhat noisy. A new -c option to vwrays (coupled with the rtcontrib -c option) is a good way to reduce noise that is available in the latest HEAD. This is a better way to reduce noise than increasing -ad, and less costly.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly faster
than 2) as the fenestration system does not have to be traced internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

Andy has proposed an improved annual simulation method, which we hope to work on next year, to remedy the direct solar sampling difficulties in the 3-phase method. It should also alleviate problems with external facade geometry and reduce the need to subdivide windows.

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

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

Yeah, this is a nice feature that obviates the need for oversampling to
reduce image noise in many cases. This feature is in the NREL packages,
BTW.

- Rob

···

On 7/25/12 4:10 PM, "Daniel C. Glaser" <[email protected]> wrote:

Dear Greg,
  Thank you for letting us know about the -c option. I am going to try
it with rtcontrib (sensors) and wanted to ask for advice on how to setup
the points for averaging. For example, if I choose 4 for -c, do I send
in the same point 4 times or is there a heuristic for perturbing or
regularly spacing these points for improving results?
  Thanks for creating this feature!

- Dan

On 7/25/2012 10:44 AM, Greg Ward wrote:

Hi Lars,

Andy probably is the right person to respond to this, but as he's on a
vacation until the end of the month, I thought I'd offer a couple of
comments (inline).

Cheers,
-Greg

From: "Lars O. Grobe" <[email protected]>
Date: July 25, 2012 1:18:42 AM PDT

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a
short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

More specifically, non-planar, specular reflectors run into trouble for
insolation. Cloudy skies or sunless skies are no problem.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than
#1, but the results are somewhat noisy. A new -c option to vwrays
(coupled with the rtcontrib -c option) is a good way to reduce noise
that is available in the latest HEAD. This is a better way to reduce
noise than increasing -ad, and less costly.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly
faster
than 2) as the fenestration system does not have to be traced
internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions
to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

Andy has proposed an improved annual simulation method, which we hope
to work on next year, to remedy the direct solar sampling difficulties
in the 3-phase method. It should also alleviate problems with external
facade geometry and reduce the need to subdivide windows.

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with
rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

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

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

Hi Dan,

If you want your sensors averaged over some small area (rather than measured at a point), then you can jitter the sample location. Otherwise, just repeat the point value N times corresponding to your -c argument.

-Greg

···

From: "Daniel C. Glaser" <[email protected]>
Date: July 25, 2012 3:10:36 PM PDT

Dear Greg,
Thank you for letting us know about the -c option. I am going to try it with rtcontrib (sensors) and wanted to ask for advice on how to setup the points for averaging. For example, if I choose 4 for -c, do I send in the same point 4 times or is there a heuristic for perturbing or regularly spacing these points for improving results?
Thanks for creating this feature!

- Dan

On 7/25/2012 10:44 AM, Greg Ward wrote:

Hi Lars,

Andy probably is the right person to respond to this, but as he's on a vacation until the end of the month, I thought I'd offer a couple of comments (inline).

Cheers,
-Greg

From: "Lars O. Grobe" <[email protected]>
Date: July 25, 2012 1:18:42 AM PDT

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

More specifically, non-planar, specular reflectors run into trouble for insolation. Cloudy skies or sunless skies are no problem.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than #1, but the results are somewhat noisy. A new -c option to vwrays (coupled with the rtcontrib -c option) is a good way to reduce noise that is available in the latest HEAD. This is a better way to reduce noise than increasing -ad, and less costly.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly faster
than 2) as the fenestration system does not have to be traced internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

Andy has proposed an improved annual simulation method, which we hope to work on next year, to remedy the direct solar sampling difficulties in the 3-phase method. It should also alleviate problems with external facade geometry and reduce the need to subdivide windows.

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

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

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

Hi Greg,
   For a preliminary trial, I passed in the same point 4 and 16 times and saw the smoothing. Thank you for incorporating this directly into these utilities!

- Dan

···

On 7/25/2012 4:21 PM, Gregory J. Ward wrote:

Hi Dan,

If you want your sensors averaged over some small area (rather than measured at a point), then you can jitter the sample location. Otherwise, just repeat the point value N times corresponding to your -c argument.

-Greg

From: "Daniel C. Glaser" <[email protected]>
Date: July 25, 2012 3:10:36 PM PDT

Dear Greg,
  Thank you for letting us know about the -c option. I am going to try it with rtcontrib (sensors) and wanted to ask for advice on how to setup the points for averaging. For example, if I choose 4 for -c, do I send in the same point 4 times or is there a heuristic for perturbing or regularly spacing these points for improving results?
  Thanks for creating this feature!

- Dan

On 7/25/2012 10:44 AM, Greg Ward wrote:

Hi Lars,

Andy probably is the right person to respond to this, but as he's on a vacation until the end of the month, I thought I'd offer a couple of comments (inline).

Cheers,
-Greg

From: "Lars O. Grobe" <[email protected]>
Date: July 25, 2012 1:18:42 AM PDT

Hi Andy, hi list-subscribers,

I just came across this recent message about the usability of the bsdf
material type with patch-based models of the sky including direct sun
and complex fenestration. To avoid misunderstandings, I will try a short
summary for others to comment on available options for annual
simulations with complex glazing:

1) classic radiance tools (rpict, rtrace), complemented by mkillum to
relax ambient setting.

Advantages: low noise, validated.

Disadvantages: very slow for annual simulations, no support when
non-planar specular reflective surfaces are involved.

More specifically, non-planar, specular reflectors run into trouble for insolation. Cloudy skies or sunless skies are no problem.

2) rtcontrib and patch-based model.

Advantages: faster for annual simulations.

Disadvantages: noise, nice images require high (slow) -ad and cannot be
optimized using mkillum, limitations about specular non-planar
reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than #1, but the results are somewhat noisy. A new -c option to vwrays (coupled with the rtcontrib -c option) is a good way to reduce noise that is available in the latest HEAD. This is a better way to reduce noise than increasing -ad, and less costly.

3) rtcontrib and patch-based model, bsdf.

Advantages: support for non-planar reflectors, should be slightly faster
than 2) as the fenestration system does not have to be traced internally
- did anyone compare?

Disadvantages: still high -ad settings required leading to extended
rendering times and still no way to get mkillum in, tends to
underestimate direct sun (according Andy's message).

4) three-phase-method.

Advantages: very fast, can also be used with non-planar specular
reflectors as bsdf data is supported.

Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
reflect external obstructions. Patches visible in the results,
fenestration geometry is not visible.

Andy has proposed an improved annual simulation method, which we hope to work on next year, to remedy the direct solar sampling difficulties in the 3-phase method. It should also alleviate problems with external facade geometry and reduce the need to subdivide windows.

5) pmap.

Advantages: can be used with non-planar reflectors and multi-peak
transmission.

Disadvantages: unknown status (any news?), not integrated with rtcontrib
(contributions would need to be rendered manually).

So if I need a way to generate images with visible fenestration
geometry, the only reliable option would be 2), which requires very
hight settings for -ad and thud will still be rather time-consuming, if
noise is to be controlled.

Cheers, Lars.

On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:

Though I've found that the BSDF material doesn't work well for
daylight coefficient based annual simulations (I'm assuming dds.bash
is a dynamic daylight simulation script). Putting the solar radiance
into skypatches relies on probabilistic sampling to find patches
containing the sun, and if you don't have much direct transmission
from the direction of the sun, you aren't likely to find the sun. Not
finding the sun causes big errors.

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

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

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

Hi Greg,

thank you for the reply. I tried a bit since, so it is almost one week
later that I can report on what I experienced so far.

> 2) rtcontrib and patch-based model. > > Advantages: faster for annual
simulations. > > Disadvantages: noise, nice images require high (slow)
-ad and cannot be > optimized using mkillum, limitations about specular
non-planar > reflectors apply.

The accuracy of non-planar, specular reflectors is actually better than
#1, but the results are somewhat noisy. A new -c option to vwrays
(coupled with the rtcontrib -c option) is a good way to reduce noise
that is available in the latest HEAD. This is a better way to reduce
noise than increasing -ad, and less costly.

Classical Radiance scenes with both "light" and "glow" sources used to
require high settings of -ad to generate "noiseless" images. This led to
something like, say, -ab 4 -ad 1024 -as 512. This was typically
impossible to render, so mkillum was used to smooth out the ambient
transmission through fenestration and keep the sharp transmission
distribution only in the direct calculation. The ambient settings would
be released to e.g. -ab 2 -ad 256 -as 128 - fast and noise-reduced.

With rtcontrib, we typically have no "light" sources any more,
everything is "glow". At the same time, mkillum is not available as a
tool any more.

It is possible to reduce the amount of rays spawned at any ambient
bounce by not increasing -ad but -c and having the jitter smooth out the
distributions from different sky patches instead. This means that
additional rays are spawned only at the first level (direct) but not for
daughter rays. However it reduces only the direct noise - noise in e.g.
shadow patterns for the patches representing the direct sun. Noise for
areas lid only by indirect, diffuse reflected light e.g. in the back of
the room is not reduced.

My guess is that the -c option aims at the same strategy as what Mark
Stock found to be promising for scenes with a lot of geometry and many
ambient bounces:

http://markjstock.org/radmisc/aa0_ps1_test/final.html

What is the actual advantage of using -c 4 instead of doubling x- and
y-resolution?

Cheers, Lars.

Hi Lars,

I'll answer your questions inline...

From: "Lars O. Grobe" <[email protected]>
Date: July 30, 2012 3:10:43 AM PDT

Hi Greg,

thank you for the reply. I tried a bit since, so it is almost one week
later that I can report on what I experienced so far.

2) rtcontrib and patch-based model. ...

The accuracy of non-planar, specular reflectors is actually better than
#1, but the results are somewhat noisy. A new -c option to vwrays
(coupled with the rtcontrib -c option) is a good way to reduce noise
that is available in the latest HEAD. This is a better way to reduce
noise than increasing -ad, and less costly.

Classical Radiance scenes with both "light" and "glow" sources used to
require high settings of -ad to generate "noiseless" images. This led to
something like, say, -ab 4 -ad 1024 -as 512. This was typically
impossible to render, so mkillum was used to smooth out the ambient
transmission through fenestration and keep the sharp transmission
distribution only in the direct calculation. The ambient settings would
be released to e.g. -ab 2 -ad 256 -as 128 - fast and noise-reduced.

With rtcontrib, we typically have no "light" sources any more,
everything is "glow". At the same time, mkillum is not available as a
tool any more.

Actually, "light" still does something in rtcontrib by attracting sample rays. It isn't always an improvement, however. The "light" type is best reserved for actual luminaires and the like -- this is what Andy found in his experiments if I remember right.

It is possible to reduce the amount of rays spawned at any ambient
bounce by not increasing -ad but -c and having the jitter smooth out the
distributions from different sky patches instead. This means that
additional rays are spawned only at the first level (direct) but not for
daughter rays. However it reduces only the direct noise - noise in e.g.
shadow patterns for the patches representing the direct sun. Noise for
areas lit only by indirect, diffuse reflected light e.g. in the back of
the room is not reduced.

Actually, all noise should be reduced somewhat.

My guess is that the -c option aims at the same strategy as what Mark
Stock found to be promising for scenes with a lot of geometry and many
ambient bounces:

http://markjstock.org/radmisc/aa0_ps1_test/final.html

What is the actual advantage of using -c 4 instead of doubling x- and
y-resolution?

Yes, I think so. The main advantage of increasing -c as opposed to -x and -y is efficiency -- the output picture files are smaller, so you don't have as much disk i/o (which can be a bottleneck) and don't have to filter the results, either.

Cheers,
-Greg

Hi Greg,

thank you for the quick reply!

What is the actual advantage of using -c 4 instead of doubling x-
and y-resolution?

Yes, I think so. The main advantage of increasing -c as opposed to
-x and -y is efficiency -- the output picture files are smaller, so
you don't have as much disk i/o (which can be a bottleneck) and don't
have to filter the results, either.

That was what I expected, but for whatever reasons, I experienced a
slowdown when setting -x and -y to 1/2 and doubling -c. Did you observe
an improvement in rendering times?

Cheers, Lars.

Hi Lars,

At least in my experiments, the rendering times always improved with increased settings of -c for the same total number of primary rays. Are you using the new rcontrib implementation or the older rtcontrib (based on rtrace)? If you are using the latter, then I'm not sure it will always help to increase -c.

The latest HEAD builds only rcontrib and puts a soft link back to rtcontrib in the binary destination directory.

Cheers,
-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: July 30, 2012 11:17:40 AM PDT

Hi Greg,

thank you for the quick reply!

What is the actual advantage of using -c 4 instead of doubling x-
and y-resolution?

Yes, I think so. The main advantage of increasing -c as opposed to
-x and -y is efficiency -- the output picture files are smaller, so
you don't have as much disk i/o (which can be a bottleneck) and don't
have to filter the results, either.

That was what I expected, but for whatever reasons, I experienced a
slowdown when setting -x and -y to 1/2 and doubling -c. Did you observe
an improvement in rendering times?

Cheers, Lars.

Hi Greg!

At least in my experiments, the rendering times always improved with
increased settings of -c for the same total number of primary rays.
Are you using the new rcontrib implementation or the older rtcontrib
(based on rtrace)? If you are using the latter, then I'm not sure it
will always help to increase -c.

A question hard to answer right now - I have to check tomorrow when I am
back on my terminal :slight_smile: But as I pulled the head-release just some days
ago, this may be the reason why. What I observed was a really
significant slow-down on a very detailed scene. I used very low settings
for -ad in this test (-ad 16) and few ambient bounces (-ab 3).

Cheers, Lars.