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

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

The documentation also states that "[#local] temporarily override any 
identifiers with the same name." IMO a bit more clarification should be 
added there, something along the lines of "...unless the identifier name 
is already in use as a macro name, or the #local statement is in a macro 
definition and the identifier name matches one of the macro parameter 
names.".

> This behavior
> breaks the very concept of local variables and makes "black box" modularization
> impossible.

Exactly, in my relatively simple macro which I doubt very many people 
have tried out yet, two people got different namespace clash related 
errors with #local's I'd used inside the macro. In future I'll make sure 
to make all variable names and parameter names unique (by prefixing with 
my name and/or the macro name etc), at which point I might just as well 
use #declare!

I can't believe more people haven't come across this "feature" in the 
last 5 years.

Post a reply to this message

Am 09.06.2013 15:12, schrieb Christian Froeschlin:

>> (In fact, why aren't coders posting more patches? Is everyone waiting
>> till 3.7 Final or something?)
>
> actually I seem to recall the license / source code comments did not
> allow the publishing of modified sources for beta versions. Not sure if
> that also holds for release candidates.

The corresponding text is still in all the file headers, so technically 
speaking I guess it does.

And yes, I can name at least one person who is holding back various 
patches for just that very reason.

Post a reply to this message