ambient resolution and memory

Hi,

I hope these messages will arrive one day when radiance-online.org is back again...

I am getting into trouble with rendering a large detailed model. If I am setting ar as usually (ar=scene boundary/detail dimensions, I get something like -ar 2000. That leads to slow processing with huge memory useage (around 1.6 GB).

I wonder if there is a way to reduce the general resolution in such cases and increase accuracy in detailed regions only by ad, as and aa.

I also wonder if there is at least some performance to win by changing / releasing ambient parameters for high-res pictures after the ouverture produced some values. While people did such things for a while, later posts suggested that this is not safe. Is this true for ALL ambient parameters?

Finally, I am using mkillum to cut one step from the ambient daylight calculation, illums are covering all windows. Does this influence the simple formula used to calculate ar, or is ar only determined by scene geometry?

I am a bit desperate, as the ambient paramters needed to produce clean images lead to rendering times about two weeks per 1200x1200 picture at the moment here, on a 3.2GHz P4... so I hope to optimize a bit by tweaking ambient calculation. I am already using mkillum and ambient exclude lists to accelerate things a bit. The scene will become even "worse" when I switch on my artificial light sources...

CU Lars.

Hi Lars,

Wow, 2 weeks. That seems pretty extreme. What is your scene? Are you running on your OpenMosix cluster?

Below are some answers and thoughts....

-Jack

Lars O. Grobe wrote:

Hi,

I hope these messages will arrive one day when radiance-online.org is back again...

I am getting into trouble with rendering a large detailed model. If I am setting ar as usually (ar=scene boundary/detail dimensions, I get something like -ar 2000. That leads to slow processing with huge memory useage (around 1.6 GB).

I wonder if there is a way to reduce the general resolution in such cases and increase accuracy in detailed regions only by ad, as and aa.

I also wonder if there is at least some performance to win by changing / releasing ambient parameters for high-res pictures after the ouverture produced some values. While people did such things for a while, later posts suggested that this is not safe. Is this true for ALL ambient parameters?

Yes, you can do this but NOT for all ambient parameters. You should be able to make some adjustments to aa, ad and as, for example:

overture calc: -aa .15 -ad 1024 -as 512
image: -aa .25 -ad 512 -as 256

where ad and as are getting halved and aa increased by some amount.

How many ambient bounces are you using? I think for an interior scene with illums at the window openings you should be able to set -ab 1....

Finally, I am using mkillum to cut one step from the ambient daylight calculation, illums are covering all windows. Does this influence the simple formula used to calculate ar, or is ar only determined by scene geometry?

I am a bit desperate, as the ambient paramters needed to produce clean images lead to rendering times about two weeks per 1200x1200 picture at the moment here, on a 3.2GHz P4... so I hope to optimize a bit by tweaking ambient calculation. I am already using mkillum and ambient exclude lists to accelerate things a bit. The scene will become even "worse" when I switch on my artificial light sources...

It may be worth it (at 2 weeks running time) to do some pretty serious experiments with ambient parameters. You might also want to consider if there is geometry that could be excluded from the ambient calculation (-ae or -aE), some examples might be very small geometry and/or geometry that has very dark materials applied. Lastly, if you have not even got your artifical lights on then you might want to consider if some of these could be managed with a glow material with a radius of influence instead of illum/light. Also worth considering is whether there are any optimizations that you might be able to do to the scene geometry...

···

--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Hi Jack!

It is a highly detailed model of an antique church with awful materials. The rendering is done on the cluster, but the rendering time of 2 weeks is per cpu.

Yes, you can do this but NOT for all ambient parameters. You should be able to make some adjustments to aa, ad and as, for example:

overture calc: -aa .15 -ad 1024 -as 512
image: -aa .25 -ad 512 -as 256

That was what I wanted to do, as it will save a lot of time (I have 70 images to render, and if only the ouverture needs high ambient settings, following images will render much faster.

How many ambient bounces are you using? I think for an interior scene with illums at the window openings you should be able to set -ab 1....

Yes, I am playing with 2 bounces at the moment, but then it is impossible to get results. I used -ab 1 before. I already have exlde lists for the ambient calculation. The glow for illumination is a nice idea, if I just want to see the position of light sources. But if they are to illuminate the scene?

I was thinking of making even heavier use of mkillum. First, bundling the light sources, so that there will be hundreds, not thousand, at least in the indirect calculation. Than it may make sense to divide the interior with illum panes, so that e.g. the light contributed from the galleries to the main room is precomputed by mkillum. Finally I may end by dividing the whole scene in virtual rooms seperated by illum panes?

Is there a patch for current radiance that allows an alternative modifier (like void) for the indirect calculation? That is available in Radzilla and might be very helpful, as I have colorpict maps on most surfaces.

Thanks & CU Lars.

Hi Lars,

Just finished with the Radiance workshop, so catching up on e-mails. This is an interesting thread...

How many ambient bounces are you using? I think for an interior scene with illums at the window openings you should be able to set -ab 1....

Yes, I am playing with 2 bounces at the moment, but then it is impossible to get results. I used -ab 1 before. I already have exlde lists for the ambient calculation. The glow for illumination is a nice idea, if I just want to see the position of light sources. But if they are to illuminate the scene?

The "glow" type with an effective radius still illuminates the scene correctly. Base your radius on the distance over which you expect your sources to be important. Past that distance, they will be considered as "indirect" sources. One important caveat: the smaller and brighter they are, the more artifacts you will see from them if your radius is too small.

Another tip to reduce calculation time if you are using a recent version of Radiance (3.6 or later) is that large surfaces in the main octree will be tracked in the shadow cache. Neither instances nor meshes will work as obstructors, so if you must instantiate geometry, leave at least some large occluders in the main octree to help in the shadow cache.

I was thinking of making even heavier use of mkillum. First, bundling the light sources, so that there will be hundreds, not thousand, at least in the indirect calculation. Than it may make sense to divide the interior with illum panes, so that e.g. the light contributed from the galleries to the main room is precomputed by mkillum. Finally I may end by dividing the whole scene in virtual rooms seperated by illum panes?

It's a curious idea. I'm not sure whether or not it will help, but I'd love to see the results.

Is there a patch for current radiance that allows an alternative modifier (like void) for the indirect calculation? That is available in Radzilla and might be very helpful, as I have colorpict maps on most surfaces.

There is no such hack. It's not really physical, is the problem.

One other note -- you might try setting -ar 0 in your case. If you have really large and small geometry that require enormous -ar settings, you may be better off without it. Alternatively, you can try excluding your ground plane from the indirect calculation with a -ae option. You can have a close-up ground plane that you include to catch the indirect from the building, then forget it outside a certain distance. This will avoid the placement of excess indirect values where nothing really is going on.

-Greg

Hi Greg!

Just finished with the Radiance workshop, so catching up on e-mails.

I am curious to hear about it, will there be a documentation cd available again? Hope ou had a nice time.

The "glow" type with an effective radius still illuminates the scene correctly. Base your radius on the distance over which you expect your sources to be important. Past that distance, they will be considered as "indirect" sources. One important caveat: the smaller and brighter they are, the more artifacts you will see from them if your radius is too small.

I will hide it behind an illum. The configuration is as follows: I group my (artificial) light sources and define one illum sphere per groups of sources. That way, first I will have much less sources in the indirect calculation, and second avoid these artefacts. Actually I was not aware about the advantage of using glow instead of light modified sources. The actual sources are small oil lamps, which I expect to be effective only indirect a groups - the room is too large compared to the lamps.

Another tip to reduce calculation time if you are using a recent version of Radiance (3.6 or later) is that large surfaces in the main octree will be tracked in the shadow cache. Neither instances nor meshes will work as obstructors, so if you must instantiate geometry, leave at least some large occluders in the main octree to help in the shadow cache.

:wink: Do you know my model that well? Thank you, this may help a lot. My model is build up in a hierarchic way, with the top elements often being instances. Maybe I should even accept overlaps just to get some occluders without changing the model too much. If I keep the visible geometry in instances, but have some large faces in the main octree a approximations to these main elements, which are invisible because completely covered by the instances' geometry, should I expect some performance gain from the shadow cache?

It's a curious idea. I'm not sure whether or not it will help, but I'd love to see the results.

I will try it. I think it highly depends on the point of view related to the scene, but in my case it may help (important viewpoints all in central hall-like room, window openings mainly in adjacent aisles/galleries etc).

There is no such hack. It's not really physical, is the problem.

Yes, but it is useful to exclude patterns and textures from the ambient and stay with the base modifier.

One other note -- you might try setting -ar 0 in your case. If you have really large and small geometry that require enormous -ar settings, you may be better off without it.

I was at around 2000, I will try 0 now.

ground plane from the indirect calculation with a -ae option.

There is none. I use the sky/ground-sphere only. It is the building's dimensions related to its details.

Thank you for your help! CU Lars.

Gregory J. Ward wrote:

Is there a patch for current radiance that allows an alternative
modifier (like void) for the indirect calculation? That is available
in Radzilla and might be very helpful, as I have colorpict maps on
most surfaces.

There is no such hack. It's not really physical, is the problem.

Hi Greg,

Since a long time already I have come to the conclusion that its better
to stay out of the discussion. I simply do some work based on and
inspired by the enourmous power and flexibility offered by Radiance,
including of course the fact that it is Open Source, and quite
evidently this also means moving away form the original path, having a
different focus in mind, probably adressing a different group of users,
whatever.
So, to repeat myself, I normally avoid bothering the Radiance community
with my thoughts.

But being misunderstood is not a very nice feeling, so for an
exceptional case I dare to make a comment on this small example.
Please everyone don't feel offended :slight_smile: :slight_smile:

In the current example you have
a) a surface made out of a material with a complicated pattern, produced
either by a function or by mapping a photo. Its an architecture scene,
so the pattern is a common building material, marble, stone, wood,
whatever, showing a fine grain color modulation in the rage of some
millimeters or centimeters

b) you have a scene with bounding cube of some 10 meters to probably 100
meters, and an -ad setting of e.g. 1000. So ambient rays send out from
one point e.g. at the floor hit walls and other objects in the big room
at points maybe several 10 centimeters apart. How much of that fine
grain resolution of the applied pattern can really be sampled by this
'few' (1000 ambient rays *are* still few in a general sense) rays?

If you now specify an average color for that material, with correctly
determined values, I dare to state that this will be equally physical
correct in the limitations of the applied algorithm and general range of
accuracy the whole stochastic ray tracing method can provide.

I of course do not mean to set a blue paint as alternative ambient
material for a red painted wall. :slight_smile:

regards
-Carsten

PS: a lot of words for just one example, but this shows quite good how
difficult it is to avoid getting misunderstood.

PPS: unfortunately, experience has shown that the performace increase by
circumventing complicated pattern evaluations for the ambient rays is
only noticable for high ambient settings and scenes with lots of
pattern-modified surfaces (especially patterns which make heavy use of
the time consuming noise functions), then it can reach 10-15%, for low
ambient settings it is sometimes not noticable at all, so one really
cannot expect too much from this hack in this respect.

PPS: but there are other cases in which the alternative ambient material
can be useful, e.g. the topic of color bleeding (see the work of Marcus
Jacobs). Here it is a crude means to simulate the white balance adaption
occuring in the human visual system within the machine by simply
reducing the amount of color bleeding 'forwarded' by the ambient
calculation.
But this is a pure image generation issue, not a scientific one, so it
doesn't belong here in this list. Also, it is only an 'intuitive'
approach (probably there is even a way of performing this based on some
physio-psycho-physical model, but evidently I have by no means at all
the resources to pursue such an approach)

Hi Lars,

Just finished with the Radiance workshop, so catching up on e-mails.

I am curious to hear about it, will there be a documentation cd available again? Hope ou had a nice time.

Yes, John plans to assemble people's talks into a CD to share at radiance-online. I'm sure he'll announce it when it's available.

The "glow" type with an effective radius still illuminates the scene correctly. Base your radius on the distance over which you expect your sources to be important. Past that distance, they will be considered as "indirect" sources. One important caveat: the smaller and brighter they are, the more artifacts you will see from them if your radius is too small.

I will hide it behind an illum. The configuration is as follows: I group my (artificial) light sources and define one illum sphere per groups of sources. That way, first I will have much less sources in the indirect calculation, and second avoid these artefacts. Actually I was not aware about the advantage of using glow instead of light modified sources. The actual sources are small oil lamps, which I expect to be effective only indirect a groups - the room is too large compared to the lamps.

This should work fine. You should set your glow radius to the diameter of your illum sphere -- assuming you are using a sphere to enclose them. Radiance will ignore all glows inside an illum, as this is a recommended optimization for light sources.

Another tip to reduce calculation time if you are using a recent version of Radiance (3.6 or later) is that large surfaces in the main octree will be tracked in the shadow cache. Neither instances nor meshes will work as obstructors, so if you must instantiate geometry, leave at least some large occluders in the main octree to help in the shadow cache.

:wink: Do you know my model that well? Thank you, this may help a lot. My model is build up in a hierarchic way, with the top elements often being instances. Maybe I should even accept overlaps just to get some occluders without changing the model too much. If I keep the visible geometry in instances, but have some large faces in the main octree a approximations to these main elements, which are invisible because completely covered by the instances' geometry, should I expect some performance gain from the shadow cache?

You should. I coded the shadow cache to look for just such "hidden" occluders.

There is no such hack. It's not really physical, is the problem.

Yes, but it is useful to exclude patterns and textures from the ambient and stay with the base modifier.

Apologies to Carsten for my careless remark. Of course, it is possible to do this correctly so that it is physical. Likewise, there are many non-physical things you can do in Radiance "classic" and care is required always if you are using any simulation as a predictive tool. As Carsten pointed out in his e-mail, this only saves substantial time when the texture/pattern evaluation is expensive, as it is for complicated procedural descriptions.

Regarding Radzilla, I'll reiterate my previous position that I am delighted about this branch, and I see it as a great service to our little corner of the Open Source world. It takes the burden off me when people ask for "artistic" additions to Radiance, which have a much better place now in Radzilla. Thanks, Carsten!

-Greg

Hi Greg,

no problem, it's allright with me :slight_smile: (I caught that phrase once in a
Phillip Marlowe movie ..)

The whole Radiance suite is simply too inspiring not only in terms of
application, but also in terms of experimenting with the code base and
with modifications and addons, as to leave all these paths untreaded.
But I couldn't agree more that all this must not have an influence on
the reliability and validation of the original code base.

And the whole point of physically realistic simulation definitely is not
an easy one, I don't mean the technical/software part right now, but the
expectations it can generate on the users side. Ok, everyone knows the
phrase 'garbage in, garbage out', but in reality life isn't that simple.
There are a lot of different steps between 100% rubbish and 100%
accurate, and accuracy itself is a relative term, accurate with respect
to which criteria? And sometimes it occurs to me like a two sided medal,
what makes Radiance so unique and useful in many fields of application,
makes it also unnecessarily difficult and restraint in other cases,
especially for those applications it wasn't made for originally :-),
regardless of the fact that it is nevertheless used for them. And that's
the interesting point then, stepping further or in different directions
without losing the contact to the roots.

many greetings
-Carsten

PS: Thank you for appreciating the radzilla branch. I mean, without your
work this would not be possible :-). The latter is evident of course,
but still worth to be mentioned.

···

--
---------------------------------------------------------

"Der Deckel muß zugehen." (P.Kölsch)

---------------------------------------------------------

Hi Lars, Greg, and Carsten,

First off. Carsten, it is always great to get you input and thoughts on Radiance related topics! So please please let us know your thoughts any time.

On the thread at hand. I just wanted to pass along to Lars. That after Greg's comments regarding the source occluder caching and instancing/meshes, I decided that I needed to do an experiment. Like you, we make heavy use of instancing to manage assembly of complex scenes from component parts. This is so much so that whole buildings will end up being an instance (even if though there is only one). From the standpoint of scene management this has been quite helpful. However after Greg's comments, I went back and recompiled a current scene making it "flat" (eg, no instances). All, I can say is WOW! The computation time was reduced significantly! So, now I am looking at the best way to add an option to produce flat scenes and make more sparing use of instancing in our scene management tool.

-Jack

Lars O. Grobe wrote:

···

Hi Greg!

Just finished with the Radiance workshop, so catching up on e-mails.

I am curious to hear about it, will there be a documentation cd available again? Hope ou had a nice time.

The "glow" type with an effective radius still illuminates the scene correctly. Base your radius on the distance over which you expect your sources to be important. Past that distance, they will be considered as "indirect" sources. One important caveat: the smaller and brighter they are, the more artifacts you will see from them if your radius is too small.

I will hide it behind an illum. The configuration is as follows: I group my (artificial) light sources and define one illum sphere per groups of sources. That way, first I will have much less sources in the indirect calculation, and second avoid these artefacts. Actually I was not aware about the advantage of using glow instead of light modified sources. The actual sources are small oil lamps, which I expect to be effective only indirect a groups - the room is too large compared to the lamps.

Another tip to reduce calculation time if you are using a recent version of Radiance (3.6 or later) is that large surfaces in the main octree will be tracked in the shadow cache. Neither instances nor meshes will work as obstructors, so if you must instantiate geometry, leave at least some large occluders in the main octree to help in the shadow cache.

:wink: Do you know my model that well? Thank you, this may help a lot. My model is build up in a hierarchic way, with the top elements often being instances. Maybe I should even accept overlaps just to get some occluders without changing the model too much. If I keep the visible geometry in instances, but have some large faces in the main octree a approximations to these main elements, which are invisible because completely covered by the instances' geometry, should I expect some performance gain from the shadow cache?

It's a curious idea. I'm not sure whether or not it will help, but I'd love to see the results.

I will try it. I think it highly depends on the point of view related to the scene, but in my case it may help (important viewpoints all in central hall-like room, window openings mainly in adjacent aisles/galleries etc).

There is no such hack. It's not really physical, is the problem.

Yes, but it is useful to exclude patterns and textures from the ambient and stay with the base modifier.

One other note -- you might try setting -ar 0 in your case. If you have really large and small geometry that require enormous -ar settings, you may be better off without it.

I was at around 2000, I will try 0 now.

ground plane from the indirect calculation with a -ae option.

There is none. I use the sky/ground-sphere only. It is the building's dimensions related to its details.

Thank you for your help! CU Lars.

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

1 Like

Brother, you said a mouthful there!

I just wanna say, Radiance, Radzilla and this great group of people who use these wonderful tools are all great. No, I haven't been drinking, I just was caught by Carsten's quotes there. Yesterday I submitted an application to speak at LIghtfair; they actually specifically want to host a seminar on Radiance this year. As I was writing up the submittal, I was forced to think back through my whole learning process with Radiance and I have to say, the last five years have been great. My discussions with Visarc Jack and Georg Mischler go back even farther than that (and all I can say is, all hail OS X, as it gives normal people access to a unix command line without the headaches of linux).

Anyway, I guess this is just a Saturday afternoon shoutout to the global Radiance community; keep up the good work!

···

On Sep 15, 2006, at 6:33 PM, Carsten Bauer wrote:

The whole Radiance suite is simply too inspiring...

And the whole point of physically realistic simulation definitely is not
an easy one...