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

On 19-6-2013 16:24, scott wrote:
>> 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).

Oh yes, I did! ;-) However, I only use SunPos for my main light source. 
I hardly use a visible sun.

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

That would be a good idea.

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

LOL good point. I admit that I was talking from a strictly personal 
point of view...


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

I am too happy with 3.7 for the things I do. ;-)

Thomas

Post a reply to this message

Consider the following scene code:

//start code
#version 3.7;

#include "colors.inc"

global_settings {assumed_gamma 1.0}

camera {
   location  <0, 5, -40>
   sky       y
   up        y
   direction z*1.7
   right     x*image_width/image_height
   angle     70
   look_at   <0, 5, 100>
}

#include "sunpos.inc"
#declare MySun  = SunPos(2012, 3, 5, 13, 10, 0, 31.7625, 25.0888);
#declare EXP = 8e-5;

// SkySim
#include "SkySim.inc"
SkySim( SolarPosition,
      y,
      5,
      EXP
    )

#declare SunColor = rgb 1;

light_source {
   MySun
   color    SunColor*(17334 * EXP)
   //parallel
   //point_at <0, 5, 100>
}


plane {y, -5 pigment {rgb 1}}
cylinder {<0,-5,10>, <0,6,10>, 1 pigment {rgb <1,0,0>}}

//end code

It renders well (see image: SkySim_SolarPosition) also with parallel and 
point_at in the light_source uncommented.

Now, switch SolarPosition in the SkySim macro call, by MySun. I get 
image SkySim_MySun.

Now, uncomment parrale and point_at in the light_source. I get image 
SkySim_MySun parallel.

So, what is wrong here? All goes well in the original test scene.

Thomas

Post a reply to this message

Attachments:
Download 'skysim_solarposition.png' (15 KB) Download 'skysim_mysun.png' (24 KB) Download 'skysim_mysun parallel.png' (15 KB)

Preview of image 'skysim_solarposition.png'

Preview of image 'skysim_mysun.png'

Preview of image 'skysim_mysun parallel.png'

On 05/07/2013 13:35, Thomas de Groot wrote:
> Consider the following scene code:
>
> //start code
> #version 3.7;
>
> #include "colors.inc"
>
> global_settings {assumed_gamma 1.0}
>
> camera {
>    location  <0, 5, -40>
>    sky       y
>    up        y
>    direction z*1.7
>    right     x*image_width/image_height
>    angle     70
>    look_at   <0, 5, 100>
> }
>
> #include "sunpos.inc"
> #declare MySun  = SunPos(2012, 3, 5, 13, 10, 0, 31.7625, 25.0888);
> #declare EXP = 8e-5;
>
> // SkySim
> #include "SkySim.inc"
> SkySim( SolarPosition,
>       y,
>       5,
>       EXP
>     )
>
> #declare SunColor = rgb 1;
>
> light_source {
>    MySun
>    color    SunColor*(17334 * EXP)
>    //parallel
>    //point_at <0, 5, 100>
> }
>
>
> plane {y, -5 pigment {rgb 1}}
> cylinder {<0,-5,10>, <0,6,10>, 1 pigment {rgb <1,0,0>}}
>
> //end code
>
> It renders well (see image: SkySim_SolarPosition) also with parallel and
> point_at in the light_source uncommented.
>
> Now, switch SolarPosition in the SkySim macro call, by MySun. I get
> image SkySim_MySun.
>
> Now, uncomment parrale and point_at in the light_source. I get image
> SkySim_MySun parallel.
>
> So, what is wrong here? All goes well in the original test scene.

Hmmm ok, so apparently I misunderstood the POV syntax, this short piece 
of code prints X=9 whereas I assumed it would print X=10. Not sure if 
this is intended behaviour or not.

// start code

#macro A(B)
#local B = B - 1;
#end

#declare X = 10;
A(X)
#warning concat("X = ",str(X,0,0))

// end code

Will fix the macro and post and update... (it's essentially normalizing 
your sun position, which you're then using the place the light source).

Post a reply to this message

On 5-7-2013 15:38, scott wrote:

> Will fix the macro and post and update... (it's essentially normalizing
> your sun position, which you're then using the place the light source).
>

Thanks! Glad to be of help (by chance) :-)

Thomas

Post a reply to this message

>
>
> Hmmm ok, so apparently I misunderstood the POV syntax, this short piece
> of code prints X=9 whereas I assumed it would print X=10. Not sure if
> this is intended behaviour or not.
>
> // start code
>
> #macro A(B)
> #local B = B - 1;
> #end
>
> #declare X = 10;
> A(X)
> #warning concat("X = ",str(X,0,0))
>
> // end code
>
> Will fix the macro and post and update... (it's essentially normalizing
> your sun position, which you're then using the place the light source).
>

Your code develop as:
#declare X = 10;
#local X = X - 1;
In this contex, #local and #declare are synonims.

So, yes, it works as expected.

There is a difference when #local is used in an include file. In an 
include, any #local variables only exist within the include.

Post a reply to this message

> Your code develop as:
> #declare X = 10;
> #local X = X - 1;
> In this contex, #local and #declare are synonims.
>
> So, yes, it works as expected.
>
> There is a difference when #local is used in an include file. In an
> include, any #local variables only exist within the include.

It is in an include, sorry in the above example the macro is in another 
file. Try this (two files):

// file1.inc
#macro A(B)
#local B = 5;
#end

// file2.pov
#include "file1.inc"
#declare X = 10;
A(X)
#warning concat("X = ",str(X,0,0))

X comes out as 5, but I would have expected 10.

Post a reply to this message

While we're at it this also causes an error (even if the definition for 
A is in a different file):

#macro A()
#end
#macro B()
#local A=1;
#end
B()

This one is a bit more serious as it means if any macro in your scene 
uses a local variable with the same name as another macro you'll get an 
error.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> While we're at it this also causes an error (even if the definition for
> A is in a different file):
>
> #macro A()
> #end
> #macro B()
> #local A=1;
> #end
> B()
>
> This one is a bit more serious as it means if any macro in your scene
> uses a local variable with the same name as another macro you'll get an
> error.

This is a known problem, although I do not know that the POV Team perceives it
as a problem.  When I brought it up 5 years ago, I was quoted documentation of
macro names being global in scope, which was just a red herring.  This behavior
breaks the very concept of local variables and makes "black box" modularization
impossible.

You also get an error if you declare a function with an argument that has the
same name as a previously declared variable.

I hope that these (and ALL other cases of scope leakage in POV-Ray) will be
eliminated by version 4.0.

Post a reply to this message