> 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

On 18-6-2013 10:52, scott wrote:
>> 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).

But mcpov has other problems of its own, as Clipka explained some time ago.

>
>> 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.

I have never met any problems or artefacts when using SunPos so, imho, 
there is no need to divide.

>
>> 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.

Maybe, but those are special cases needing special solutions.

>
> At this point I usually fire up mcpov :-)

<grin>

Thomas

Post a reply to this message

> But mcpov has other problems of its own, as Clipka explained some time ago.

The only major one is the diffuse values are out by a factor of 2, I 
usually use a macro for setting the finish which outputs either the 
vanilla POV syntax (for testing the scene) or the mcpov syntax (for 
final render). Incorporating the factor of 2 correction is easy in the 
macro.

> I have never met any problems or artefacts when using SunPos so, imho,
> there is no need to divide.

That's just because you never tried to put a sphere at that position 
before :-) Also I haven't done a thorough investigation, but the 
accuracy issues you run into seem to depend on the size of other objects 
in your scene (and maybe the camera setup?). Whilst the /1000 factor for 
placing the sphere might work in this particular scene, it may become 
invisible again in a different scene (or work fine without the /1000).

I suppose the ultimate solution would be to incorporate the sun in the 
sky_sphere pigment at the physically correct brightness (which would 
save having to use any arbitrary values for "very far away"), and for 
the POV team to implement something similar to the sky importance 
sampling in mcpov for the radiosity algorithm (so you don't need a 
really high count to reliably pick up the bright sun).

> Maybe, but those are special cases needing special solutions.

I never thought I'd hear a glossy reflective surface being called a 
"special case" in a raytracing forum - what next, a checkered plane is 
also a special case? :-O

>> At this point I usually fire up mcpov :-)
>
> <grin>

Bring on mcpov merged into POV 3.7 !! If I had the time I'd definitely 
give it a shot.

Post a reply to this message