> Hello,
> 
> I have trouble getting the lighting right for an outdoor scene. I use an HDR
> sky, radiosity and a ground plane. In this image, it appears that the sky casts
> light onto the box from the left, but there are no shadows.
> 
> Also, the white plane is too dark.
> 
> The HDR sky is https://polyhaven.com/a/lilienstein. The relevant part of the
> code is
> 
> 
> global_settings {
>      radiosity {
>        pretrace_end 0.001
>        count 500
> 
>        recursion_limit 1
> 
>        low_error_factor 0.2
>        brightness 1
>     }
> }
> 
You are using the default error_bound of 1.8.
Try using a smaller value, like 0.5 and see if the shadows are visible.

global_settings {
     radiosity {
       pretrace_end 0.001
       count 500

       recursion_limit 1
	error_bound 0.5 // Should give sharper shadows
       low_error_factor 0.4
// With a smaller error_bound, it can be set larger
       // brightness 1 Not needed as it's the default
    }
}

Another thing to check : Where is the Sun in the sky. Try another HDR 
with the Sun closer to the horizon.

Post a reply to this message

There isn't much more shadow even with error_bound 0.01. What it does is that it
changes the pattern on the left side of the cube.

The sun is near the horizon in the hdri.

Post a reply to this message

Attachments:
Download 'test.png' (831 KB)

Preview of image 'test.png'

"borix" <nomail@nomail> wrote:
> There isn't much more shadow even with error_bound 0.01. What it does is
> that it changes the pattern on the left side of the cube.
>
> The sun is near the horizon in the hdri.

To add to what Alain said: With a few 'higher quality' radiosity settings, I do
see a shadow. I think each person has his or her own set of 'favorite'
settings-- mine change on a weekly basis, ha.

My own *basic* rule-of-thumb is to use very small settings for
minimum_reuse ...
maximum_reuse ...

This creates smaller light 'patches', which more accurately get into and around
corners, etc. (But then other rad values need to be tuned as well, including a
higher count to get ride of that splotchy 'pattern' you mentioned. All of which
naturally makes for a slower render...)

I was actually surprised that I *do* see a shadow; the particular HDR image that
you used has a somewhat uniform sky color/brightness, with the
Sun below the horizon. Also, the 'dark' result on the plane is probably a
natural result of the relatively dark sky in most of that image.

----- example -----
#version 3.8; // or whatever

global_settings {
assumed_gamma 1
    radiosity {
      pretrace_end 0.001
      count 1100
      recursion_limit 1

      // [I added these three...]
      minimum_reuse .0032
      maximum_reuse .0032*5
      always_sample on // off by default. I prefer this ON

      low_error_factor 0.2
      brightness 1
   }
}

camera {
  perspective
  location  <10, 11, -20>
  look_at   <10, 4,  0>
  right     x*image_width/image_height
  angle 67
}


sky_sphere{
    pigment{
        image_map{ hdr "lilienstein_4k.hdr"
        map_type 1 interpolate 2}
           }
}

box {
    <0,0,0>, <8,8,8>
    pigment {rgb <239, 204, 148>/255}
    rotate 35*y

}

plane {
    y, 0
    pigment { rgb 1}
}

Post a reply to this message

Attachments:
Download 'better_shadow.jpg' (39 KB)

Preview of image 'better_shadow.jpg'

> There isn't much more shadow even with error_bound 0.01. What it does is that it
> changes the pattern on the left side of the cube.
> 
> The sun is near the horizon in the hdri.
> 

I do see a shadow to the right of the box. In fact, there are two, one 
faint and soft, in line with the front face, and a darker and sharper 


I NEVER use the default pretrace_end. The largest I commonly use is 
0.005. I often use half or even a quarter of that for the final rendering.
It takes more time for the pretrace step, but, as more samples are taken 
during that phase, the render proper is often faster as it don't need to 
take as many extra samples.

I tend to set minimum_reuse a bit smaller than the pretrace_end. 
Something like :

pretrace_end 0.005
minimum_reuse 0.004

pretrace_end 0.0025
minimum_reuse 0.002

or

pretrace_end 0.00125
minimum_reuse 0.0012

I also tend to keep the maximum_reuse at it's default value.

I usually use the sampling pool feature :
count 100 100*pi

And also the adaptive sampling :
nearest_count 20 3

Post a reply to this message

The lighting is getting better with different settings, but the shadow is still
too weak and the plane too dark. I use an additionl light now, that's easier to
control.

Post a reply to this message

"borix" <nomail@nomail> wrote:
> The lighting is getting better with different settings, but the shadow is still
> too weak and the plane too dark. I use an additionl light now, that's easier to
> control.

I see that you have no finish {} block for your pigment.  Maybe define a full
texture with a finish that you can see what effect changing the diffuse setting
on accomplishes.
I don't know offhand what the default finish values are...

Post a reply to this message

Op 29/09/2021 om 17:57 schreef Alain Martel:
> I do see a shadow to the right of the box. In fact, there are two, one 
> faint and soft, in line with the front face, and a darker and sharper 

> 
[snip]

Absolutely. Using Alain's settings for radiosity, and, instead of a 
skysphere:

   sphere {
     0, 10e5
     pigment{
         image_map {exr "lilienstein_4k.exr"
         map_type 1 interpolate 2 once}
     }
       finish {emission 2 diffuse 0}
}

and, adding micro-normals to the cube and the plane:

     normal {granite 0.2 scale 0.001}


I get the attached image.

Note that as the sunlight in the hdr/exr is rather diffuse, the shadows 
are also diffuse.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'sky_test.jpg' (50 KB)

Preview of image 'sky_test.jpg'

Op 29-9-2021 om 07:21 schreef Kenneth:
>        always_sample on // off by default. I prefer this ON
> 

The Voodoo Master teaches about this (in 2008):

[quote]
always_sample:
When set to "off", this effectively sets "nearest_count" to 1 during the 
final render, so that new radiosity samples are only taken if they are 
absolutely needed.

For quick test renders, you may want to set this parameter to "on" to 
get away with a faster pretrace (or none at all).

Otherwise, you will definitely want to set this parameter to "off", as 
new samples taken during final trace may cause visible "jumps" in colour 
or brightness between areas rendered before and after the new sample was 
taken.

(Note that I recommend to set "nearest_count" to 1 anyway, which leaves 
this option without any effect.)
[/quote]

;-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 29-9-2021 om 07:21 schreef Kenneth:
> >        always_sample on // off by default. I prefer this ON
> >
>
> The Voodoo Master teaches about this (in 2008):
>
> [quote]
> always_sample:
> When set to "off", this effectively sets "nearest_count" to 1 during the
> final render, so that new radiosity samples are only taken if they are
> absolutely needed.
>
> For quick test renders, you may want to set this parameter to "on" to
> get away with a faster pretrace (or none at all).
>
> Otherwise, you will definitely want to set this parameter to "off", as
> new samples taken during final trace may cause visible "jumps" in colour
> or brightness between areas rendered before and after the new sample was
> taken.
>

Yes, I remember reading that. Several months ago, I did some lengthy and
detailed tests with radiosity (which I *hope* to post about soon...), and my own
eyes tell me that the final render looks 'better' with always_sample on.
Specifically, it seems to eliminate some very subtle artifacts that I noticed;
as a simple way of describing the effect, it produced a 'smoother' render
IMO...but hard to describe, unfortunately. However, all of my tests used a
single small rad emitting object in a scene (and no sky_sphere), as I wanted to
try and zero-in on the basic behavior of radiosity and its various settings.

I could be wrong, but it may be that this particular feature of rad has been
improved since Clipka posted that info(?)

Or it could be just my personal preference, ha. As the old saying goes,
"One man's meat is another man's poison" (which may not translate well?)

;-)

Post a reply to this message

Op 30-9-2021 om 20:11 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 29-9-2021 om 07:21 schreef Kenneth:
>>>         always_sample on // off by default. I prefer this ON
>>>
>>
>> The Voodoo Master teaches about this (in 2008):
>>
>> [quote]
>> always_sample:
>> When set to "off", this effectively sets "nearest_count" to 1 during the
>> final render, so that new radiosity samples are only taken if they are
>> absolutely needed.
>>
>> For quick test renders, you may want to set this parameter to "on" to
>> get away with a faster pretrace (or none at all).
>>
>> Otherwise, you will definitely want to set this parameter to "off", as
>> new samples taken during final trace may cause visible "jumps" in colour
>> or brightness between areas rendered before and after the new sample was
>> taken.
>>
> 
> Yes, I remember reading that. Several months ago, I did some lengthy and
> detailed tests with radiosity (which I *hope* to post about soon...), and my own
> eyes tell me that the final render looks 'better' with always_sample on.
> Specifically, it seems to eliminate some very subtle artifacts that I noticed;
> as a simple way of describing the effect, it produced a 'smoother' render
> IMO...but hard to describe, unfortunately. However, all of my tests used a
> single small rad emitting object in a scene (and no sky_sphere), as I wanted to
> try and zero-in on the basic behavior of radiosity and its various settings.
> 
> I could be wrong, but it may be that this particular feature of rad has been
> improved since Clipka posted that info(?)
> 
> Or it could be just my personal preference, ha. As the old saying goes,
> "One man's meat is another man's poison" (which may not translate well?)
> 
> ;-)
> 

You might well be right. While posting my Clipka comment, I realised 
that he was writing at a time when version 3.7 was still in a 
development mode. I would be curious to have his updated view on this, 
in particular for version 3.8.

-- 
Thomas

Post a reply to this message