> 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