Rendering large space with small detail (small picture now attached!)

radiance-general
1

Hello,

I’m using Ecotect as the geometry interface and file generator to Radiance.

For day-lighting purposes, I’m modelling a large space which includes areas
of small detail. After many lengthy iterations (20+ hours for each
simulation) the best image I could generate is the image attached.

My problems are the splotchy nature of the light being reflected off the
ceiling space and the baffled louvers under the skylight. The render
settings that I used to generate the image are as follows;

*-dp=*

*-ar=*

*-ms=*

*-ds=*

*-dt=*

*-dc=*

*-dr=*

*-sj=*

*-st=*

*-ab=*

*-af=*

*-aa=*

*-ad=*

*-as=*

*-av=*

*-lr=*

*-lw=*

512

128

3.4

0.3

0.1

0.5

1

0.7

0.1

8

RCP.amb

0.1

1023

512

0.01 0.01 0.01

6

0

I’ve increased the accuracy of the variables which I thought were critical
to the accuracy of the render. These were; ambient resolution (ar), ambient
bounces (ab), ambient accuracy (aa), ambient divisions (ad) and ambient
super-samples (as).

Is it a case of increasing the accuracy of these specific variables further
or is there an easier or quicker way to achieve better rendering?

Any help would be greatly appreciated.

Thanks,

7.jpg800×525 40.1 KB

···

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

2

Hi Paul,

Bottom line, the easiest way to avoid splotchy artifacts is to bring the direct light contributions closer and closer to the surfaces visible in the image. I'm having a hard time understanding what the lighting design is in this image. There seems to be a cove or something on the left, and some baffled ceiling condition to the right of that, that changes in plan. maybe you could describe the lighting design and the section of that ceiling? Where is the skylight and what is the section of that in relation to this scene? What are the characteristics of the media between the external daylight and the interior scene? That information might inform a solution to these rendering issues (because there may be a solution to them that takes less than 20 hours to get results better than what you have posted). Either way, for a scene this apparent size, the -ar seems low right off the bat; also, the -ab is way high for an image (generally speaking); and the -ad and -as are probably too low.

···

On May 18, 2009, at 6:32 PM, Paul Chilton wrote:

Hello,

I’m using Ecotect as the geometry interface and file generator to Radiance.

For day-lighting purposes, I’m modelling a large space which includes areas of small detail. After many lengthy iterations (20+ hours for each simulation) the best image I could generate is the image attached.

My problems are the splotchy nature of the light being reflected off the ceiling space and the baffled louvers under the skylight. The render settings that I used to generate the image are as follows;

-dp=
-ar=
-ms=
-ds=
-dt=
-dc=
-dr=
-sj=
-st=
-ab=
-af=
-aa=
-ad=
-as=
-av=
-lr=
-lw=
512
128
3.4
0.3
0.1
0.5
1
0.7
0.1
8
RCP.amb
0.1
1023
512
0.01 0.01 0.01
6
0

I’ve increased the accuracy of the variables which I thought were critical to the accuracy of the render. These were; ambient resolution (ar), ambient bounces (ab), ambient accuracy (aa), ambient divisions (ad) and ambient super-samples (as).

Is it a case of increasing the accuracy of these specific variables further or is there an easier or quicker way to achieve better rendering?

Any help would be greatly appreciated.

Thanks,

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]
<7.jpg>_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

3

Hi Rob,

Thanks for your help.

I'll try to explain better what is happening in the image. As you look at
the image you are looking down the spine of a supermarket mall. Right in
front of the camera position is a void in the floor to the ground floor
below. On the immediate left (I assume this is the 'cove' you talk about) is
another space perpendicular to the mall which is a food court. To the right
and left are glazed shop fronts with the first shop front on the left
showing a reflection of the scene behind the camera position. The cubic
looking geometry are 1m high kiosks in the centre of the mall space. The
baffles hanging from the ceiling are internal shading devices which are
hiding a horizontal skylight above which stretches the length of the mall.
The left top strip of baffles are external shading devices covering the
vertical clerestory windows which again run the length of the mall.

The electric lighting you can see inside the shops fronts are very generic
and are simply there so that the shops don't look like dungeons for the
purpose of the image. The primary focus and motivation for the image is the
day light conditions in the mall space and so the mall space has no electric
lighting - just the shops.

The outside ambient conditions are a uniform sky.

You say;

'the easiest way to avoid splotchy artifacts is to bring the direct light
contributions closer and closer to the surfaces visible in the image'

I'm unsure exactly what you mean here as the direct light contributions are
the external sky and therefore how would you bring this closer to the
surfaces to create better resolution?

Thanks for your reccomendations on the variables, I'll try doubling the
variables you said were too low and seeing if that has a better effect.

Cheers,

Paul.

···

On Tue, May 19, 2009 at 3:03 PM, Rob Guglielmetti <[email protected]>wrote:

Hi Paul,

Bottom line, the easiest way to avoid splotchy artifacts is to bring the
direct light contributions closer and closer to the surfaces visible in the
image. I'm having a hard time understanding what the lighting design is in
this image. There seems to be a cove or something on the left, and some
baffled ceiling condition to the right of that, that changes in plan. maybe
you could describe the lighting design and the section of that ceiling?
Where is the skylight and what is the section of that in relation to this
scene? What are the characteristics of the media between the external
daylight and the interior scene? That information might inform a solution to
these rendering issues (because there may be a solution to them that takes
less than 20 hours to get results better than what you have posted). Either
way, for a scene this apparent size, the -ar seems low right off the bat;
also, the -ab is way high for an image (generally speaking); and the -ad and
-as are probably too low.

  On May 18, 2009, at 6:32 PM, Paul Chilton wrote:

  Hello,

I’m using Ecotect as the geometry interface and file generator to Radiance.

For day-lighting purposes, I’m modelling a large space which includes areas
of small detail. After many lengthy iterations (20+ hours for each
simulation) the best image I could generate is the image attached.

My problems are the splotchy nature of the light being reflected off the
ceiling space and the baffled louvers under the skylight. The render
settings that I used to generate the image are as follows;

  *-dp=*
*-ar=*
*-ms=*
*-ds=*
*-dt=*
*-dc=*
*-dr=*
*-sj=*
*-st=*
*-ab=*
*-af=*
*-aa=*
*-ad=*
*-as=*
*-av=*
*-lr=*
*-lw=*
512
128
3.4
0.3
0.1
0.5
1
0.7
0.1
8
RCP.amb
0.1
1023
512
0.01 0.01 0.01
6
0

I’ve increased the accuracy of the variables which I thought were critical
to the accuracy of the render. These were; ambient resolution (ar), ambient
bounces (ab), ambient accuracy (aa), ambient divisions (ad) and ambient
super-samples (as).

Is it a case of increasing the accuracy of these specific variables further
or is there an easier or quicker way to achieve better rendering?

Any help would be greatly appreciated.

Thanks,

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]
<7.jpg>_______________________________________________
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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

4

Hi,

as Rob said, bringing the light source closer to the scene is a good start :wink: You can do this in your case by using the gensky modifier for your horizontal skylight's glazing, instead of defining a glass pane plus an outside sky dome (I assume that you do not have any visible geometry that is seen through the horizontal skylight). The second is that in your case, it may be possible to define an mkillum surface in the vertical clerestory windows. This would produce an uniform illum source accounting for the external blinds and certainly help a lot to improve rendering times with acceptable image quality.

I would try to go with such a set-up. Replace the (vertical) clerestory glazing with a mkillum surface, the (horizontal) skylight glazing with the gensky modifier, and set higher ambient paramters as Rob suggested (and set a lower -ab, 2 or 3 should be fine with a good -av value!!!).

In case this is not enough - one COULD try to introduce a second mkillum surface below the internal shades, as these probably also are a bit tricky to calculate. In this case, one would place a gensurf-generated surface just below the internal shades, with a resolution to account for variations in the structure (I would try something like 4x4 from what I see on the image), which will be invisible, but replace all ambient calculations on top of the internat shades by 4x4 illum sources. This would lead to a very simple scene, with very short rendering times and virtually no noise. BUT - first try the other options!

CU Lars.

···

--
Lars O. Grobe (Mr) :: Research Fellow, Solar Energy Research Institute of Singapore SERIS :: National University of Singapore :: Block 4 Engineering Drive 3, #E4-01-01, Singapore 117576 :: 65-6516 5816(Tel) :: 65-6775 1943 (Fax) :: [email protected] (E) :: www.seris.sg (W) :: Company Registration No: 200604346E

Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

5

Paul,

The outside ambient conditions are a uniform sky.

Is there a particular reason to use a uniform sky over the CIE overcast?

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Reader in Daylight Modelling
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]

6

Hi John,

I want to be able to test the daylight and sun penetration in the mall space
during different sky conditions eg 9am 12pm 3pm sunny sky and also an
overcast sky. So in hindsight I should've used the CIE overcast. However,
when I simulate with sunny sky conditions I get the same resolution and
rendering problems.

Any more thoughts?

Paul.

···

On Tue, May 19, 2009 at 2:01 AM, John Mardaljevic <[email protected]> wrote:

Paul,

The outside ambient conditions are a uniform sky.

Is there a particular reason to use a uniform sky over the CIE overcast?

-John

-----------------------------------------------
Dr. John Mardaljevic
Reader in Daylight Modelling
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
Institute of Energy and Sustainable Development <http://www.iesd.dmu.ac.uk/~jm&gt;

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

7

I want to be able to test the daylight and sun penetration in the mall space during different sky conditions eg 9am 12pm 3pm sunny sky and also an overcast sky. So in hindsight I should've used the CIE overcast. However, when I simulate with sunny sky conditions I get the same resolution and rendering problems.

Any more thoughts?

Paul.

Hi Paul,

using not the uniform sky does not solve the problem, I guess that John asked because the uniform sky is not really a model of what you could observe in nature, so few people use it for anything but testing.

To solve your problem, several comments and hints have been given, and I would suggest that you try these. As a note, the mkillum tool is actually a way to get useable results without setting ambient parameters too high, a performance boost so to say, In your case, you would have to expect really high rendering times without such techniques.

If you wonder why you see the splotchy shades, look into how Radiance is rendering the ambient. The problem is the limited number of sample rays sent out for each bounce, to random directions. So for one point, most rays may hit the shade, while for a point just a cm aside, which should receive more or less the same irradiation, you may be lucky enough to hit the sky with all sampled rays. And than, this calculation is not done for each point in space, but only if the variation exceeds limits, the ambient resolution enforces it, .... and so on. So you COULD set ar, as very high, increase the ar setting, set a low aa, and wait.

The mkillum tool will optimize the calculation a lot, as it replaces the complex geometry outside the scene by a light source, so that is why I recommended it. It is always useful in cases of so-called complex fenestration, and your sun-shades are. If you think very creative, you could even consider the layer of internal sunshades as 'complex fenestration' (ok, no glass, but similar problems here), so I added the idea to have a mkillum surface here, too. But I guess that mkillum for the vertical clerestory windows, skyfunc for the horizontal skylight, and moderate ambient settings for the scene than should give acceptable results.

Do you have the book "Rendering with Radiance", as well as Axel Jacobs tutorials? These should give you an idea why you experience problems with you scene, as well as strategies how to solve these. And you should find examples on how to use mkillum, too.

CU Lars.

8

Hi Lars,

Thanks for you help.

I don't have the 'Rendering in Radiance' book but I am seriously considering
getting a copy. I have however found the tutorials. I've used the radiance
tutorial chapter 5 - Outside Geometry to help aid me in trying to set up a
mkillum tool. However, it seems that my editing is not working.

In the .rif file, I'm creating the mkillum function which I've used the
tutorial example is; mkillum= -av 18 18 18 -ab 0 . I then go into the .rad
file to find the properties and geometry of the skylight and then copy and
paste those values and descriptions separately into a new .rad file and save
it as window.rad. In the .rif file I then refer to this window.rad file by
specifying illum= window.rad. My interpretation of this procedure is that
rather than the ambient being the generator of light into the space it is
now the window itself which is the light source.

When I simulate this with sunny sky conditions I expect to see no direct sun
patches into the space as the skylight essentially has been transformed into
a diffuser - but this is not the case as I continue to get direct sunlight
into the space.

I feel that there needs to be some kind of luminance component in
the window.rad file, not just the window properties and geometry.

Is there anything wrong with what I'm doing? I've attached the files if it
helps to explain what I've done.

Thanks again.

Paul.

testformkillum.rad (5.96 KB)

testformkillum.rif (743 Bytes)

window.rad (209 Bytes)

···

On Tue, May 19, 2009 at 9:01 PM, Lars O. Grobe <[email protected]> wrote:

I want to be able to test the daylight and sun penetration in the mall

space during different sky conditions eg 9am 12pm 3pm sunny sky and also an
overcast sky. So in hindsight I should've used the CIE overcast. However,
when I simulate with sunny sky conditions I get the same resolution and
rendering problems.

Any more thoughts?

Paul.

Hi Paul,

using not the uniform sky does not solve the problem, I guess that John
asked because the uniform sky is not really a model of what you could
observe in nature, so few people use it for anything but testing.

To solve your problem, several comments and hints have been given, and I
would suggest that you try these. As a note, the mkillum tool is actually a
way to get useable results without setting ambient parameters too high, a
performance boost so to say, In your case, you would have to expect really
high rendering times without such techniques.

If you wonder why you see the splotchy shades, look into how Radiance is
rendering the ambient. The problem is the limited number of sample rays sent
out for each bounce, to random directions. So for one point, most rays may
hit the shade, while for a point just a cm aside, which should receive more
or less the same irradiation, you may be lucky enough to hit the sky with
all sampled rays. And than, this calculation is not done for each point in
space, but only if the variation exceeds limits, the ambient resolution
enforces it, .... and so on. So you COULD set ar, as very high, increase the
ar setting, set a low aa, and wait.

The mkillum tool will optimize the calculation a lot, as it replaces the
complex geometry outside the scene by a light source, so that is why I
recommended it. It is always useful in cases of so-called complex
fenestration, and your sun-shades are. If you think very creative, you could
even consider the layer of internal sunshades as 'complex fenestration' (ok,
no glass, but similar problems here), so I added the idea to have a mkillum
surface here, too. But I guess that mkillum for the vertical clerestory
windows, skyfunc for the horizontal skylight, and moderate ambient settings
for the scene than should give acceptable results.

Do you have the book "Rendering with Radiance", as well as Axel Jacobs
tutorials? These should give you an idea why you experience problems with
you scene, as well as strategies how to solve these. And you should find
examples on how to use mkillum, too.

CU Lars.

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

9

Hi Paul!

I do not have much time right now, so only a short answer.

The fact that you still see the direct sun hit inside surfaces is expected. The illum surface just replaces the indirect component (the background sky and outside reflections), not the direct light, for which it appears to be transparent or as the secondary modifiert you use it with.

If you want to see whether everything is fine, generate the mkillum sources with a sky without direct sun.

Cheers

Lars.

···

--
Lars O. Grobe (Mr) :: Research Fellow, Solar Energy Research Institute of Singapore SERIS :: National University of Singapore :: Block 4 Engineering Drive 3, #E4-01-01, Singapore 117576 :: 65-6516 5816(Tel) :: 65-6775 1943 (Fax) :: [email protected] (E) :: www.seris.sg (W) :: Company Registration No: 200604346E

Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

10

Hi Paul,

So you're on your way. Lars has explained that mkillum will do the "bringing of the direct component closer to your scene" as I suggested. A couple of other pointers:

You want to create impostor geometry or define your skylight apertures as illum sources. You do this by adding "illum=" lines to the .rif file. Let's say you have a skylight defined by a skylight.rad file, that describes the polygons that make up the skylight opening; you would remove that reference from the "scene=" line(s) and add an "illum=" line. You are telling rad to take any polygons defined in the illum= files and do a backwards raytrace from those polygons and out into the scene beyond. Generally this is the exterior environment, and as such the rays traced stand a much better chance of hitting the sun. The results of this raytrace operation are saved and applied as a data file to the polygons defining the skylight or aperture and that aperture becomes a light source. I would not worry about an -av value for your mkillum= line, but I would definitely increase the -ab value to 2 or 3, and -ad 512.

You should not do anything to the .rad files from there. rad is great; if you tell rad (via the illum= line(s)) which surfaces should be precalculated as light sources, rad will manage the creation of these secondary light sources as they are called and create its own separate rad files that substitute the precalculated illums for the calculations and/or renderings. Definitely look at the rad manual page for more info on this...

- Rob Guglielmetti

···

On May 19, 2009, at 8:09 PM, Paul Chilton wrote:

In the .rif file, I'm creating the mkillum function which I've used the tutorial example is; mkillum= -av 18 18 18 -ab 0 . I then go into the .rad file to find the properties and geometry of the skylight and then copy and paste those values and descriptions separately into a new .rad file and save it as window.rad. In the .rif file I then refer to this window.rad file by specifying illum= window.rad. My interpretation of this procedure is that rather than the ambient being the generator of light into the space it is now the window itself which is the light source.

11

Hi Rob, Lars,

Thanks for all your help and suggestions. I'll be giving them a try tomorrow
with a fresh pair of eyes. I'll let you know how I get on.

Regards,

Paul.

···

On Wed, May 20, 2009 at 2:09 PM, Rob Guglielmetti <[email protected]>wrote:

On May 19, 2009, at 8:09 PM, Paul Chilton wrote:

In the .rif file, I'm creating the mkillum function which I've used the
tutorial example is; mkillum= -av 18 18 18 -ab 0 . I then go into the .rad
file to find the properties and geometry of the skylight and then copy and
paste those values and descriptions separately into a new .rad file and save
it as window.rad. In the .rif file I then refer to this window.rad file by
specifying illum= window.rad. My interpretation of this procedure is that
rather than the ambient being the generator of light into the space it is
now the window itself which is the light source.

Hi Paul,

So you're on your way. Lars has explained that mkillum will do the
"bringing of the direct component closer to your scene" as I suggested. A
couple of other pointers:

You want to create impostor geometry or define your skylight apertures as
illum sources. You do this by adding "illum=" lines to the .rif file. Let's
say you have a skylight defined by a skylight.rad file, that describes the
polygons that make up the skylight opening; you would remove that reference
from the "scene=" line(s) and add an "illum=" line. You are telling rad to
take any polygons defined in the illum= files and do a backwards raytrace
from those polygons and out into the scene beyond. Generally this is the
exterior environment, and as such the rays traced stand a much better chance
of hitting the sun. The results of this raytrace operation are saved and
applied as a data file to the polygons defining the skylight or aperture and
that aperture becomes a light source. I would not worry about an -av value
for your mkillum= line, but I would definitely increase the -ab value to 2
or 3, and -ad 512.

You should not do anything to the .rad files from there. rad is great; if
you tell rad (via the illum= line(s)) which surfaces should be precalculated
as light sources, rad will manage the creation of these secondary light
sources as they are called and create its own separate rad files that
substitute the precalculated illums for the calculations and/or renderings.
Definitely look at the rad manual page for more info on this...

- Rob Guglielmetti

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

12

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for the
skylight. The render times are reduced and the images displayed look
different too.

However, I have been testing the use of the mkillum without the artificial
lighting turned on in my model. When I do turn them on and run them with the
parameters set to high accuracy levels, the simulation takes a very long
time. I think that any time gained by the mkillum surface is negated by the
number of lights it has to simulate.

Is there a way of simplifying the artificial lighting of the tenants either
side of the mall space? The goal of the artificial lighting in the tenancies
is not to be highly accurate but rather to give the daylight in the mall
space some context and to make it look more realistic as I’m only concerned
about the daylight in the mall. Ideally I would like to put a mkillum
surface in the position of the array of lights but I feel that this wouldn’t
help reduce the complexity of the simulation as the same number of
calculations still need to be carried out, am I right?

Is there a way in Radiance to make a planer object emit a certain amount of
uniform light?

Look forward to hearing from you,

Paul

···

On Wed, May 20, 2009 at 2:09 PM, Rob Guglielmetti <[email protected]>wrote:

On May 19, 2009, at 8:09 PM, Paul Chilton wrote:

In the .rif file, I'm creating the mkillum function which I've used the
tutorial example is; mkillum= -av 18 18 18 -ab 0 . I then go into the .rad
file to find the properties and geometry of the skylight and then copy and
paste those values and descriptions separately into a new .rad file and save
it as window.rad. In the .rif file I then refer to this window.rad file by
specifying illum= window.rad. My interpretation of this procedure is that
rather than the ambient being the generator of light into the space it is
now the window itself which is the light source.

Hi Paul,

So you're on your way. Lars has explained that mkillum will do the
"bringing of the direct component closer to your scene" as I suggested. A
couple of other pointers:

You want to create impostor geometry or define your skylight apertures as
illum sources. You do this by adding "illum=" lines to the .rif file. Let's
say you have a skylight defined by a skylight.rad file, that describes the
polygons that make up the skylight opening; you would remove that reference
from the "scene=" line(s) and add an "illum=" line. You are telling rad to
take any polygons defined in the illum= files and do a backwards raytrace
from those polygons and out into the scene beyond. Generally this is the
exterior environment, and as such the rays traced stand a much better chance
of hitting the sun. The results of this raytrace operation are saved and
applied as a data file to the polygons defining the skylight or aperture and
that aperture becomes a light source. I would not worry about an -av value
for your mkillum= line, but I would definitely increase the -ab value to 2
or 3, and -ad 512.

You should not do anything to the .rad files from there. rad is great; if
you tell rad (via the illum= line(s)) which surfaces should be precalculated
as light sources, rad will manage the creation of these secondary light
sources as they are called and create its own separate rad files that
substitute the precalculated illums for the calculations and/or renderings.
Definitely look at the rad manual page for more info on this...

- Rob Guglielmetti

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

13

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for the skylight. The render times are reduced and the images displayed look different too.

However, I have been testing the use of the mkillum without the artificial lighting turned on in my model. When I do turn them on and run them with the parameters set to high accuracy levels, the simulation takes a very long time. I think that any time gained by the mkillum surface is negated by the number of lights it has to simulate.

The simulations will increase as you increase the number of light sources, that is a fact of life (or virtual life, as in this case). The mkillum process will help improve the speed and accuracy of the lighting simulation of the light filtering in from the skylight, but as you add in complexity through electric light sources, you will experience a delay in the simulation times, yes.

Is there a way of simplifying the artificial lighting of the tenants either side of the mall space? The goal of the artificial lighting in the tenancies is not to be highly accurate but rather to give the daylight in the mall space some context and to make it look more realistic as I’m only concerned about the daylight in the mall. Ideally I would like to put a mkillum surface in the position of the array of lights but I feel that this wouldn’t help reduce the complexity of the simulation as the same number of calculations still need to be carried out, am I right?

The electric lights probably aren't doing much in terms of contribution to the overall lighting that is predominantly from the skylight. In this case you can use the glow material for your lights (with a small radius, see the docs) to affect a visual context as you are looking for without exacting a huge penalty on the render time.

Is there a way in Radiance to make a planer object emit a certain amount of uniform light?

Yep, the glow is the material you want for this. I have used it infrequently but I believe this is exactly what you need to get these renderings looking good and completing in reasonable timeframes.

- Rob Guglielmetti

···

On May 26, 2009, at 8:07 PM, Paul Chilton wrote:

14

Hi Paul,

Another tip:

If you are planning to simulate several sky conditions and times, you should
consider separating the electric light and daylight into two simulations.
Once you have a single rendering of the electric lighting and multiple
renderings of the daylight scenarios you can add the electric light
rendering to each daylight rendering using pcomb. This saves the time of
rendering electric lighting with every daylight condition.

Also, since you are less concerned about the accuracy of the electric
lighting you might consider adjusting the -dt parameter. If I remember
correctly the most computationally expensive part is the shadow testing.
Increasing -dt reduces the number of shadow tests performed and should speed
up the simulation significantly.

andy

···

On 5/26/09 10:08 PM, "Rob Guglielmetti" <[email protected]> wrote:

On May 26, 2009, at 8:07 PM, Paul Chilton wrote:

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for
the skylight. The render times are reduced and the images displayed
look different too.

However, I have been testing the use of the mkillum without the
artificial lighting turned on in my model. When I do turn them on
and run them with the parameters set to high accuracy levels, the
simulation takes a very long time. I think that any time gained by
the mkillum surface is negated by the number of lights it has to
simulate.

The simulations will increase as you increase the number of light
sources, that is a fact of life (or virtual life, as in this case).
The mkillum process will help improve the speed and accuracy of the
lighting simulation of the light filtering in from the skylight, but
as you add in complexity through electric light sources, you will
experience a delay in the simulation times, yes.

Is there a way of simplifying the artificial lighting of the tenants
either side of the mall space? The goal of the artificial lighting
in the tenancies is not to be highly accurate but rather to give the
daylight in the mall space some context and to make it look more
realistic as I¹m only concerned about the daylight in the mall.
Ideally I would like to put a mkillum surface in the position of the
array of lights but I feel that this wouldn¹t help reduce the
complexity of the simulation as the same number of calculations
still need to be carried out, am I right?

The electric lights probably aren't doing much in terms of
contribution to the overall lighting that is predominantly from the
skylight. In this case you can use the glow material for your lights
(with a small radius, see the docs) to affect a visual context as you
are looking for without exacting a huge penalty on the render time.

Is there a way in Radiance to make a planer object emit a certain
amount of uniform light?

Yep, the glow is the material you want for this. I have used it
infrequently but I believe this is exactly what you need to get these
renderings looking good and completing in reasonable timeframes.

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

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

15

Hi Rob, Andy,

Thank you both for you suggestions. I've been concentrating on getting the
glow material to properly work first.

I've looked at the Radiance reference manual and read the description of
glow. In my rad file I've made a new glow material:

*void glow* glowsurface
0
0
4 0.898 0.898 0.898 50

and I've changed the name of the polygon that I want to glow from it's
original surface name of 'plaster_insulated' to the name specified above
i.e. 'glowsurface'. However in my image the surface appears to be black and
I've tried changing the maxrad variable but this hasn't had an effect. I've
read what it says about maxrad but I'm still unsure of what it is
exactly and what the variable range is (is it a 0-1?) and what a typical
value is.
Could you please help?

Regards,

Paul.

···

On Wed, May 27, 2009 at 3:08 PM, Rob Guglielmetti <[email protected]>wrote:

On May 26, 2009, at 8:07 PM, Paul Chilton wrote:

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for the
skylight. The render times are reduced and the images displayed look
different too.

However, I have been testing the use of the mkillum without the artificial
lighting turned on in my model. When I do turn them on and run them with the
parameters set to high accuracy levels, the simulation takes a very long
time. I think that any time gained by the mkillum surface is negated by the
number of lights it has to simulate.

The simulations will increase as you increase the number of light sources,
that is a fact of life (or virtual life, as in this case). The mkillum
process will help improve the speed and accuracy of the lighting simulation
of the light filtering in from the skylight, but as you add in complexity
through electric light sources, you will experience a delay in the
simulation times, yes.

Is there a way of simplifying the artificial lighting of the tenants either

side of the mall space? The goal of the artificial lighting in the tenancies
is not to be highly accurate but rather to give the daylight in the mall
space some context and to make it look more realistic as I’m only concerned
about the daylight in the mall. Ideally I would like to put a mkillum
surface in the position of the array of lights but I feel that this wouldn’t
help reduce the complexity of the simulation as the same number of
calculations still need to be carried out, am I right?

The electric lights probably aren't doing much in terms of contribution to
the overall lighting that is predominantly from the skylight. In this case
you can use the glow material for your lights (with a small radius, see the
docs) to affect a visual context as you are looking for without exacting a
huge penalty on the render time.

Is there a way in Radiance to make a planer object emit a certain amount
of uniform light?

Yep, the glow is the material you want for this. I have used it
infrequently but I believe this is exactly what you need to get these
renderings looking good and completing in reasonable timeframes.

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

16

Hi Paul.

Since a glow functions like a light source the material is sensitive to the orientation of the normal for the “glowing” polygon geometry. Thus when a glow material such as:

void glow test.glow

0

0

4 1 1 1 0

is applied to a polygon, the “front” side of the polygon (eg, the positive normal) will glow with a radiance of 1 (in the above case) whereas the backside of the polygon (the negative normal) will appear black.

So in your case any polygons that appear black need to be re-oriented, so they glow in the right direction. There are a couple of ways to check and fix this. The way we usually check is to apply a glow material to the selected geometry and then objview just the selected geometry. This way we can do a quick visual check. Now if you are lucky, all the geometry either points in the right direction or it does not. If this is the case and all the geometry is black, then you can do:

xform -I original_geometry.rad > original_geometry.flipped.rad

This will flip the orientation of all the normals in original_geometry.rad. If on the other hand there is a mix of glowing and black polygons then you will have to go back into your modeling application and figure out how to flip things either by rebuilding the geometry or some other strategy. In Autocad (for example) 3dfaces that are built in a clockwise manner will have the normal pointing out of the clockwise face (I hope I am remembering this correctly).

The fourth argument of a glow specifies a sphere of influence for the glow, resulting in illumination localized within the specified radius (the fourth argument is the radius in the model units within which the glow will essentially act like a light). So in other words a glow can actually be used to illuminate things. So you should be thoughtful about how you specify this value, to little and things may not be illuminated locally (if they need to be at all), to big and you basically have another light source in the scene. I think that Andy suggested you could break the scene down between interior electric lighting and various daylighting scenarios, with results being the combination of electric plus the desired daylighting. You can probably go one step further and break out the glow related “lighting” and run that separately. The thinking would be that this would allow you to test and tune your glow materials if that makes sense.

More generally there are a couple of other items to consider. By using mkillum you have essentially “moved” the resulting light into the space, because of this you may be able to use a lower -ab setting such as -ab 1. On the other hand, if some of your illum surfaces span large areas, you will need to set -ds (direct sampling) to subdivide these surfaces essentially “spreading” the light out over the surface rather than samping the middle of the polygon. You may also need to experiment with -dj (direct jitter).

I hope this helps.

Regards,

-Jack de Valpine

Paul Chilton wrote:

Hi Rob, Andy,

Thank you both for you suggestions. I’ve been concentrating on getting the glow material to properly work first.

I’ve looked at the Radiance reference manual and read the description of glow. In my rad file I’ve made a new glow material:

void glow glowsurface

0

0

4 0.898 0.898 0.898 50

and I’ve changed the name of the polygon that I want to glow from it’s original surface name of ‘plaster_insulated’ to the name specified above i.e. ‘glowsurface’. However in my image the surface appears to be black and I’ve tried changing the maxrad variable but this hasn’t had an effect. I’ve read what it says about maxrad but I’m still unsure of what it is exactly and what the variable range is (is it a 0-1?) and what a typical value is.

Could you please help?

Regards,

Paul.

–

Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]



---

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

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

On Wed, May 27, 2009 at 3:08 PM, Rob Guglielmetti [email protected]
wrote:

On May 26, 2009, at 8:07 PM, Paul Chilton wrote:

The simulations will increase as you increase the number of light sources, that is a fact of life (or virtual life, as in this case). The mkillum process will help improve the speed and accuracy of the lighting simulation of the light filtering in from the skylight, but as you add in complexity through electric light sources, you will experience a delay in the simulation times, yes.

The electric lights probably aren’t doing much in terms of contribution to the overall lighting that is predominantly from the skylight. In this case you can use the glow material for your lights (with a small radius, see the docs) to affect a visual context as you are looking for without exacting a huge penalty on the render time.

Yep, the glow is the material you want for this. I have used it infrequently but I believe this is exactly what you need to get these renderings looking good and completing in reasonable timeframes.

  • Rob Guglielmetti

Radiance-general mailing list

[email protected]

[http://www.radiance-online.org/mailman/listinfo/radiance-general](http://www.radiance-online.org/mailman/listinfo/radiance-general)

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for the skylight. The render times are reduced and the images displayed look different too.

However, I have been testing the use of the mkillum without the artificial lighting turned on in my model. When I do turn them on and run them with the parameters set to high accuracy levels, the simulation takes a very long time. I think that any time gained by the mkillum surface is negated by the number of lights it has to simulate.
Is there a way of simplifying the artificial lighting of the tenants either side of the mall space? The goal of the artificial lighting in the tenancies is not to be highly accurate but rather to give the daylight in the mall space some context and to make it look more realistic as I’m only concerned about the daylight in the mall. Ideally I would like to put a mkillum surface in the position of the array of lights but I feel that this wouldn’t help reduce the complexity of the simulation as the same number of calculations still need to be carried out, am I right?

Is there a way in Radiance to make a planer object emit a certain amount of uniform light?

17

Hi Rob,
[snip]

In Autocad (for example) 3dfaces that
are built in a clockwise manner will have the normal pointing out of
the clockwise face (I hope I am remembering this correctly).
    
It's hard to tell from your description if you are or not. Think of it
this way: let's say you are drawing a polygon that represents the face
(screen) of the computer monitor you are now staring at. If you draw the
points in a clockwise fashion, the surface normal will be pointing away
from you (out the back of the monitor). If you define it with points in a
COUNTER-clockwise fashion, the polygon's surface normal will be pointing
at you. IOW, in the first example, with a glow applied, the monitor face
would render black. In the latter example, the monitor face would glow.

This can be reinforced by a permutation of the so-called "right hand
rule". Take your right hand and point at your face with your thumb, and
then curve your fingers around the axis defined by your thumb; if you
imagine your fingers pointing in the direction of rotation (and direction
of point creation), your thumb describes the surface normal (vector).

Ack, yes you are absolutely correct! I knew I should have gone and actually checked.... Another way to consider this, if you are working in the XY plane (Autocad based example here) then counter clockwise gets you a normal point in positive Z.

Of course this really applies to surface generated geometry. Solid modeling will bring its own set of issues with geometry management....

-Jack

···

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

18

Hi Jack,

Thanks for that tip, it seems to work. Reversing the normals was very easy,
I use Ecotect as the CAD interface to radiance and it was just a case of
selecting the object and hitting 'cntrl R'.

I'll be running the simulation over the weekend with the new glow surfaces
in replacement of the lights to see how much quicker it is.

As for you suggestions about ab, dj and ds parameters, I'll give them a try
separately once I have the glow sorted.

Thanks again,

Regards,

Paul.

···

On Thu, May 28, 2009 at 11:50 PM, Jack de Valpine <[email protected]> wrote:

Hi Paul.

Since a glow functions like a light source the material is sensitive to the
orientation of the normal for the "glowing" polygon geometry. Thus when a
glow material such as:

void glow test.glow
0
0
4 1 1 1 0

is applied to a polygon, the "front" side of the polygon (eg, the positive
normal) will glow with a radiance of 1 (in the above case) whereas the
backside of the polygon (the negative normal) will appear black.

So in your case any polygons that appear black need to be re-oriented, so
they glow in the right direction. There are a couple of ways to check and
fix this. The way we usually check is to apply a glow material to the
selected geometry and then objview just the selected geometry. This way we
can do a quick visual check. Now if you are lucky, all the geometry either
points in the right direction or it does not. If this is the case and all
the geometry is black, then you can do:

xform -I original_geometry.rad > original_geometry.flipped.rad

This will flip the orientation of all the normals in original_geometry.rad.
If on the other hand there is a mix of glowing and black polygons then you
will have to go back into your modeling application and figure out how to
flip things either by rebuilding the geometry or some other strategy. In
Autocad (for example) 3dfaces that are built in a clockwise manner will have
the normal pointing out of the clockwise face (I hope I am remembering this
correctly).

The fourth argument of a glow specifies a sphere of influence for the glow,
resulting in illumination localized within the specified radius (the fourth
argument is the radius in the model units within which the glow will
essentially act like a light). So in other words a glow can actually be used
to illuminate things. So you should be thoughtful about how you specify this
value, to little and things may not be illuminated locally (if they need to
be at all), to big and you basically have another light source in the scene.
I think that Andy suggested you could break the scene down between interior
electric lighting and various daylighting scenarios, with results being the
combination of electric plus the desired daylighting. You can probably go
one step further and break out the glow related "lighting" and run that
separately. The thinking would be that this would allow you to test and tune
your glow materials if that makes sense.

More generally there are a couple of other items to consider. By using
mkillum you have essentially "moved" the resulting light into the space,
because of this you may be able to use a lower -ab setting such as -ab 1. On
the other hand, if some of your illum surfaces span large areas, you will
need to set -ds (direct sampling) to subdivide these surfaces essentially
"spreading" the light out over the surface rather than samping the middle of
the polygon. You may also need to experiment with -dj (direct jitter).

I hope this helps.

Regards,

-Jack de Valpine

Paul Chilton wrote:

  Hi Rob, Andy,

Thank you both for you suggestions. I've been concentrating on getting the
glow material to properly work first.

I've looked at the Radiance reference manual and read the description of
glow. In my rad file I've made a new glow material:

*void glow* glowsurface
0
0
4 0.898 0.898 0.898 50

and I've changed the name of the polygon that I want to glow from it's
original surface name of 'plaster_insulated' to the name specified above
i.e. 'glowsurface'. However in my image the surface appears to be black and
I've tried changing the maxrad variable but this hasn't had an effect. I've
read what it says about maxrad but I'm still unsure of what it is
exactly and what the variable range is (is it a 0-1?) and what a typical
value is.
Could you please help?

Regards,

Paul.
On Wed, May 27, 2009 at 3:08 PM, Rob Guglielmetti <[email protected]>wrote:

On May 26, 2009, at 8:07 PM, Paul Chilton wrote:

Hi Lars, Rob

It looks like I have managed to get the mkillum surface to work for the
skylight. The render times are reduced and the images displayed look
different too.

However, I have been testing the use of the mkillum without the
artificial lighting turned on in my model. When I do turn them on and run
them with the parameters set to high accuracy levels, the simulation takes a
very long time. I think that any time gained by the mkillum surface is
negated by the number of lights it has to simulate.

The simulations will increase as you increase the number of light sources,
that is a fact of life (or virtual life, as in this case). The mkillum
process will help improve the speed and accuracy of the lighting simulation
of the light filtering in from the skylight, but as you add in complexity
through electric light sources, you will experience a delay in the
simulation times, yes.

Is there a way of simplifying the artificial lighting of the tenants

either side of the mall space? The goal of the artificial lighting in the
tenancies is not to be highly accurate but rather to give the daylight in
the mall space some context and to make it look more realistic as I’m only
concerned about the daylight in the mall. Ideally I would like to put a
mkillum surface in the position of the array of lights but I feel that this
wouldn’t help reduce the complexity of the simulation as the same number of
calculations still need to be carried out, am I right?

The electric lights probably aren't doing much in terms of contribution to
the overall lighting that is predominantly from the skylight. In this case
you can use the glow material for your lights (with a small radius, see the
docs) to affect a visual context as you are looking for without exacting a
huge penalty on the render time.

Is there a way in Radiance to make a planer object emit a certain amount
of uniform light?

Yep, the glow is the material you want for this. I have used it
infrequently but I believe this is exactly what you need to get these
renderings looking good and completing in reasonable timeframes.

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]

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

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

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

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

--
Paul Chilton

Renewable Energy Engineer

[m] 0400 306 791 | [e] [email protected]