rtcontrib and rtrace-parameters

Dear radiance gurus,

based on Axel´s extremely helpful tutorial, I started to use rtcontrib. At the end of the day the target is annual daylight simulation, but at the moment there are questions quite at the beginning.
I have a small test room, quite similar to Axel´s without any sun protection. I did two rtrace runs for clear sky conditions. The first sky (k4) gives direct sun for the first two measurement points, with the second sky (k5) there is no sun entering the room.
For the rtcontrib run I use reinhart.cal and compared two MF-settings (2 and 4). The rtrace-options are -ab 6 -ad 4096 -as 2048 -aa 0 -dj 1 -lw 2e-10.
With this settings I get the distributions in Graph1 http://www.meinalbum.at/Foto-LRSDFU3V-D.jpg
To get the distribution I use genskyvec.
Additional I did some rtrace runs with the same options und compared the results for sky k4 in the second graph http://www.meinalbum.at/Foto-CKMDQR4R-D.jpg

To this results the are some questions:
1.) Are this useful rtrace-options, am I on the right track?
2.) What can I do, to get closer to the rtrace-results?
3.) MF=2 seems to get smoother results, than MF=4 - dose that make sense?
4.) Can I reduce the differences between different rtrace-runs with the identical options?

Any comments are very appreciated.

Thank you
Martin Klingler

Hi Martin.

The first sky (k4) gives direct sun for the first two measurement points,
with the second sky (k5) there is no sun entering the room.
For the rtcontrib run I use reinhart.cal and compared two MF-settings (2
and 4). The rtrace-options are –ab 6 –ad 4096 –as 2048 –aa 0 –dj 1 –lw
2e-10.
With this settings I get the distributions in Graph1

[graph removed]

To get the distribution I use genskyvec.
Additional I did some rtrace runs with the same options und compared the
results for sky k4 in the second graph

I think you wanted to write 'rtcontrib runs' - at least that's what your
labels say.

When you use genskyvec you also remove the sun 'source' from the sky
description and distribute its brightness to the surrounding sky patches.
rtace treats a sky with sun differently than a sky without sun. Therefore
you will not achieve identical results from rtrace and rtcontrib.

[graph removed]

To this results the are some questions:
1.) Are this useful rtrace-options, am I on the right track?

That obviously depends on your scene complexity. If you have blinds in front
of your window I would say that the results you get are sufficiently
accurate for climate data studies.

If you have a simple geometry like in Axel's tutorial I think that the -as
2048 is overkill. You already have a high -ad setting which should account
for window openings in a typical room.

Effectively you have turned off ambient caching by setting -aa to 0.
rtcontrib does not use ambient caching anyway so that's probably not going
to make a difference. Ambient caching might have smoothed out your
individual point results a bit.

Your -dj value seems high, but given that there are no sources it should not
matter.

2.) What can I do, to get closer to the rtrace-results?

As I said above, you can not reproduce the direct calculation with
genskyvec. You could split out the direct component and do a separate
calculation just for the sun. It will just make things far more complicated,
though.

You could try and switch off Monte Carlo sampling with '-u-'. That should
give you a deterministic sampling pattern which should result in 'identical'
values.

3.) MF=2 seems to get smoother results, than MF=4 - dose that make
sense?

4.) Can I reduce the differences between different rtrace-runs with the

identical options?

rtcontrib-runs?

Perhaps you should investigate where the error originates in your
calculation chain. When you use rtcontrib to calculate illuminance values at
a point the only value affected by the rtrace options is the contribution of
each sky patch. This is only a fraction of the 'brightness' the patch is
ultimately assigned so small variations in the contribution can result in
noticeable changes of the illuminance values. I would start by comparing the
patch contributions between rtcontrib runs. If they are reasonably constant
your error is introduced somewhere else.

IIRC the multiplier for each patch contribution is calculated via genskyvec
at specified directions (saved in tregsamp.dat). That should result in
constant values for the multipliers but you can still check.

Overall I think that your current values are sufficiently accurate. In the
end you will apply these values to a large number of (inaccurate) sky
descriptions to then calculate an average from all these results. The error
you introduce by the use of insufficient sky models should largely exceed
the error resulting from the rtcontrib/genskyvec process.

Anyway, good that there is more interest in validating climate data
calculations.

Regards,
Thomas

···

On Sat, Mar 6, 2010 at 5:37 PM, Martin Klingler <[email protected]>wrote:

That would mean, if I am only interested in daylight (in combination with
rtcontrib), I can forget aa and dj and reduce as.

I would think that '-as' can be reduced but that depends on your geometry.

As far as I understand it options affecting the ambient interpolation
('-aa' and '-ar') will have no effect because rtcontrib needs to
disable the interpolation ('-aa 0'). Any source related option will
have no effect because the base sky used to calculate the patches does
not have a source. After that any sky is sampled at predefined angles
which makes most rtrace options obsolete.

I would start by comparing the patch contributions between rtcontrib runs.
If they are reasonably constant your error is introduced somewhere else.

That is a good point. I am quite sure, that the differences are coming from
the patch contributions. The calculation time for the rtcontrib run is extremely
short, at least I think so.

Yes, that surprised me, too. I haven't done any testing on serious
scene where multiple reflections should lead to a contribution of
almost every sky patch. In my test scene at first every patch 'behind'
the window wall was ignored because there was nothing to bounce light
back into the room. The I introduced another building in front of my
room to reflect a more realistic scenario.

I don't know what good values for rtcontrib would be. It simply uses
rtrace in a fancy way so all parameters that apply to an rtrace
calculation in the same scene should be fine (see exceptions above).

What are the critical parameters concerning accuracy for a rtcontrib run, I
really wouldn't have any problems with longer computation time.

Perhaps we just have to use ridiculously high '-ad' values to make
sure the sky is sampled at a high density. This would result in less
variation due to the number of rays that hit a specific sky patch.

IIRC the multiplier for each patch contribution is calculated via genskyvec
at specified directions (saved in tregsamp.dat). That should result in
constant values for the multipliers but you can still check.

OK, they are constatnt over simmilar calls to genskyvec.

Ah, good to know.

The error you introduce by the use of insufficient sky models
should largely exceed the error resulting from the rtcontrib/genskyvec
process.

Thank you for that comment. Yes that is true. But can I say that as
long as I compare different daylighting solutions with the same
(inaccurate) processes, I will get still valid results?

With Radiance there will always be some 'inaccuracy'. All we can do is
try to understand where the error is introduced and how we can
estimate its magnitude (as you're doing right now). If your rtrace
results are within 5% of the rtrace results for the same scene then
that might be the built-in inaccuracy of rtcontrib.

Add that to the difference between sky model and real sky and you may
end up with 20-30% inaccuracy for the whole climate data based
approach. That's what we have to live with until we can coax another
student into writing a better sky generator or a more accurate
rtcontrib ...

However, even with this high error margin we can now at least start to
work on daylight models that take into account the weather, seasons,
location and orientation of buildings. I won't start calculating ADF
with rtcontrib; rtrace is much better in doing that. But perhaps there
is some information to be found in a RDF ('real daylight factor') that
can efficiently only be calculated with something like rtcontrib.

Regards,
Thomas

···

On Mon, Mar 8, 2010 at 7:51 PM, Martin Klingler <[email protected]> wrote: