"jr" <cre### [at] gmailcom> wrote:
>
> running into a different problem with 'povr_6e4ed6c2', the sky_sphere code was
> originally copied from the docs, and the image renders fine with 'beta.2':
>
> File 'o22.pov' line 207:
> Possible Parse Error:
> Unmatched {
> File 'o22.pov' line 217:
> Parse Error:
> No matching }, emission found instead
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> 206
> 207 sky_sphere {
> 208   pigment {
> 209     gradient y
> 210     color_map {
> 211       [.5 color rgb <.74902,.847059,.847059>]
> 212       [1  color rgb <.258824,.258824,.435294>]
> 213     }
> 214     scale 2.5
> 215     translate -1
> 216   }
> 217   emission rgb <.825,.825,1>
> 218 }
> 219
>

[running v3.8.0 beta 1 in Windows 10]
It parses and renders OK for me as well.

But that example in the docs is a rather strange one, IMO-- only because the
explicitly-given 'emission' color *changes* the color_map's colors.

The docs say that the intended(?) result of the example is this:
"This gives a soft blend from CornflowerBlue at the horizon to MidnightBlue at
the zenith."

But not so; the given emission component values are simple multipliers, and
produce a slightly different color. I have never actually used an explicit
'emission' for a sky_sphere; it's the common understanding that it is set to 1.0
behind-the-scenes as a default (so that the sky_sphere's colors are successfully
used in radiosity, for example).

BTW, I find it interesting that the sky_sphere syntax does not accept an actual
finish{...} block, like...

     finish{emission rgb <.825,.825,1>}

.... even though it does accept a pigment{...} block.

Post a reply to this message