>> You can adjust the EXP variable in the test scene to control the
>> brightness of the sky (it controls how the physical brightness values
>> calculated are converted to POV units). Try increasing it from 4e-5 to
>> 6e-5 or even higher.
>
> Yes I did that indeed, but somehow the scene never comes close to the
> aspect of a regular light and sky_sphere.

It looks like it's because the sun is so bright and so small, the 
radiosity algorithm won't pick it up very often. This would explain the 
bright yellow patches, they're radiosity samples that just happened to 
pick up the sun - most of the samples didn't. I'm not experienced enough 
with radiosity to know a way around this (I use mcpov for most renders, 
which allows for such small very bright objects ok).

Could you ever get a similar scene with a realistically sized and bright 
sun to render with radiosity corerctly? The pigment of the sky_sphere 
should only make a very minor difference when a bright sun is in the sky.

> I added radiosity, and they seem to come from that. Without radiosity
> the landscape remains totally dark whatever the value for EXP and the
> hour of the day.

There was a light_source in my demo scene file I posted, that should 
illuminate the ground - unless you've uncommented the sun sphere that 
happens to be in exactly the same place :-)

 > I think I found the culprit: Your original SunPos() is divided by 1000!

That shouldn't make a difference, because the sun radius is determined 
from the distance. The reason I did that is because SunPos.inc returns a 
massive distance for the sun vector which causes problems in some 
scenes, in reality it only needs to be a few orders of magnitude further 
away than everything else in your scene.

Post a reply to this message

On 17-6-2013 16:21, scott wrote:

> That shouldn't make a difference, because the sun radius is determined
> from the distance. The reason I did that is because SunPos.inc returns a
> massive distance for the sun vector which causes problems in some
> scenes, in reality it only needs to be a few orders of magnitude further
> away than everything else in your scene.
>

And yet, *that* is exactly the trouble maker. Without, the scene renders 
perfectly, like the example (with radiosity added again) shows. Also in 
any other of my scenes the results are correct. Exp at 4e-5 again here.

Thomas

Post a reply to this message

Attachments:
Download 'skysimtestground.png' (160 KB)

Preview of image 'skysimtestground.png'

> I added radiosity, and they seem to come from that. Without radiosity
> the landscape remains totally dark whatever the value for EXP and the
> hour of the day.

Thinking about, you can have light_sources and still use radiosity can't 
you? In that case I don't see any benefit to using a sphere for the sun 
over using a light_source (even an area_light if you want realistic soft 
shadows).

The only reason I left the sphere object in there is because in mcpov 
you can't use light_sources, you are forced to model a sun as a very 
bright sphere.

Post a reply to this message

>> That shouldn't make a difference, because the sun radius is determined
>> from the distance. The reason I did that is because SunPos.inc returns a
>> massive distance for the sun vector which causes problems in some
>> scenes, in reality it only needs to be a few orders of magnitude further
>> away than everything else in your scene.
>
> And yet, *that* is exactly the trouble maker. Without, the scene renders
> perfectly, like the example (with radiosity added again) shows. Also in
> any other of my scenes the results are correct. Exp at 4e-5 again here.

If you want to post your two scene files (the one that renders correctly 
and the one that has the bright blobs) then I'll take a look and see if 
I can figure out what's going on.

Post a reply to this message

On 17-6-2013 16:45, scott wrote:
> If you want to post your two scene files (the one that renders correctly
> and the one that has the bright blobs) then I'll take a look and see if
> I can figure out what's going on.

It is very simple: the only thing to do is to comment out the /1000 at 
the end of the SunPos() declaration in your scene file. You may want to 
add the radiosity code (below).

As radiosity I use:

   radiosity {
     pretrace_start 0.08
     pretrace_end   0.004
     count 50, 1000
     nearest_count 10, 5
     error_bound 1
     recursion_limit 2
     low_error_factor .3
     gray_threshold 0.0
     minimum_reuse 0.015
     maximum_reuse 0.1							
     brightness 1
     adc_bailout 0.01/2
     normal off
     media off
     always_sample off
     //max_sample 1.0
   }

Note that without the divisor, the sun sphere (when switched on) becomes 
invisible somehow.

Thomas

Post a reply to this message

On 17-6-2013 16:41, scott wrote:

> Thinking about, you can have light_sources and still use radiosity can't
> you? In that case I don't see any benefit to using a sphere for the sun
> over using a light_source (even an area_light if you want realistic soft
> shadows).

Your scene uses a light_source, therefore the visibility switch should 
switch on the looks_like code there.

Thomas

Post a reply to this message

> Note that without the divisor, the sun sphere (when switched on) becomes
> invisible somehow.

It also becomes invisible to the whole radiosity algorithm... Try it 
with the sphere commented out - I get exactly the same image with and 
without the sphere when the /1000 divisor is deleted.

If you look at sunpos.inc near the bottom you see this line:

    #declare SolarPosition=vrotate(<0,0,1000000000>,<-Al,Az,0>);

That 1000000000 is simply too big - accuracy errors prevent an object at 
that distance rendering properly, even directly or from the radiosity code.

Anyway, the splotchiness is because the sun is too small, so the 
radiosity algorithm doesn't always pick it up. By taking out the /1000 
you are effectively removing the sun sphere from the scene so the 
splotchiness goes away (along with any radiosity effect from the sun).

To test this simply make your sun sphere much bigger (and reduce the 
emission so the amount of light stays constant), here I made it 50x bigger:

#local SunRadius = vlength(sp)/214.8 * 50;
sphere{ sp,SunRadius pigment{color rgb 1} finish{emission 1.6e9 * EXP / 
50/50 }}

That makes it 50 times bigger and it renders fine (no bright splotches) 
with your radiosity settings - see attached.

Without upping the count to silly levels I don't know how else to get an 
emissive sun of a realistic size to show up with radiosity. You'd be 
better off sticking with an area_light IMHO.

Post a reply to this message

Attachments:
Download 'bigsun.png' (145 KB)

Preview of image 'bigsun.png'

On 17-6-2013 17:10, Thomas de Groot wrote:
> Your scene uses a light_source, therefore the visibility switch should
> switch on the looks_like code there.

Re-reading my own post, I find it totally confusing :-)

What I mean is that instead of a sphere, you could add the looks_like 
code to the light_source.

Thomas

Post a reply to this message

There is a much better solution.

//start code

#local sp = SunPos(2013, 6, 6, 17, 0, 0, 52.206507, 0.12165);

light_source {
   sp
   color rgb <1,1,0.9>*(17334 * EXP)
}

#local SunRadius = vlength(sp/1000)/214.8;
sphere {sp/1000, SunRadius pigment{color rgb 1} finish{emission 1} 
no_shadow}

//end code

The scene does not need the *emission* of the *visible* sphere as a 
light source. It only needs the light source itself. So, the solution is 
to put the sunlight at the standard SunPos position, and the *visible* 
sphere and its radius at sp/1000. In addition, just make emission of the 
sphere equal to 1.

See attached image.

Thomas

Post a reply to this message

Attachments:
Download 'skysimtestground.png' (207 KB)

Preview of image 'skysimtestground.png'

> There is a much better solution.
...
> The scene does not need the *emission* of the *visible* sphere as a
> light source.

As I said before, there isn't any need to try this for radiosity, it 
will just cause problems like you experienced. It's only in the code as 
it is needed for mcpov (where is works fine).

> It only needs the light source itself. So, the solution is
> to put the sunlight at the standard SunPos position, and the *visible*
> sphere and its radius at sp/1000.

I don't know if there are any accuracy issues related to having a 
light_source a very large distance away, I expect it may cause some 
shadow artifacts? The length of the vector from SunPos is quite 
arbitrary, so in every scene you just need to find the max distance it 
works at, then I'd probably divide by 10 or 100 just to be sure you're 
not near the accuracy limit.

> In addition, just make emission of the
> sphere equal to 1.

The problem with that is the sun will look unrealistically dim compared 
to the sky when visible in any reflections, especially darker low-level 
reflections (eg a black car). You could set emission to 0 and ambient to 
the original physically correct 1.6e9 * EXP, but I think that would 
still influence the radiosity algorithm and give you back the bright 
splotches again.

At this point I usually fire up mcpov :-)

Post a reply to this message