I have been testing POV 3.6.1's sunpos.inc #include file, with some virtual
landscapes I am familiar with, based upon USGS DEMs. I am obtaining
incorrect results; the sun does not rise or set when it should.

I have set year, month, day, hour, minute, timezone offset, longitude and
latitude correctly. I am rendering scenes I have rendered hundreds of times
before with accurate sun positions. Now it's all wrong.

Hence sunpos.inc must be broken. Anybody else with sunpos.inc problems?

I used to use a very similar file named "sun.inc,' which worked exactly
right and took the same paramemters in the same order and format, as
sunpos.inc. However, under POV 3.6.1 this sun.inc file does not run, but
gives an error message in parsing, saying that it does not recognixe "vstr"
in the line

#macro vstr (vec)

This makes me think that #macro syntax must have changed between version 3.1
and 3.6; but I can't see how.

Help?

Thanks

Post a reply to this message

"Russell Towle" <rto### [at] inreachcom> wrote:
>However, under POV 3.6.1 this sun.inc file does not run, but
> gives an error message in parsing, saying that it does not recognixe 
> "vstr"
> in the line
>
> #macro vstr (vec)
>
> This makes me think that #macro syntax must have changed between version 
> 3.1
> and 3.6; but I can't see how.

No, but in POV-Ray 3.6 vstr is a reserved keyword. Renaming vstr to VStr (or 
similar) everywhere might fix the problem.

Rune
-- 
http://runevision.com

Post a reply to this message

"Rune" <new### [at] runevisioncom> wrote:
> "Russell Towle" <rto### [at] inreachcom> wrote:
> >However, under POV 3.6.1 this sun.inc file does not run, but
> > gives an error message in parsing, saying that it does not recognixe
> > "vstr"
> > in the line
> >
> > #macro vstr (vec)
> >
> > This makes me think that #macro syntax must have changed between version
> > 3.1
> > and 3.6; but I can't see how.
>
> No, but in POV-Ray 3.6 vstr is a reserved keyword. Renaming vstr to VStr (or
> similar) everywhere might fix the problem.

Ah ha! Well I will try that, or I should try that, but, ...

I got the standard #include sunpos.inc to work. I was mistakenly writing
"-8" for my timezone when this particular algorithm wants -8*15 (degrees).
Once I fixed that, my suns behaved normally.

Thanks Rune!

RT

Post a reply to this message

Russell Towle <rto### [at] inreachcom> wrote:
> I got the standard #include sunpos.inc to work. I was mistakenly writing
> "-8" for my timezone when this particular algorithm wants -8*15 (degrees).
> Once I fixed that, my suns behaved normally.

  Thus we once again see that you shouldn't be too hasty in deciding that
it's the program/library/whatever that is broken and not your code...

-- 
                                                          - Warp

Post a reply to this message