I've been away from the newsgroups for awhile-- busy running lots of radiosity
tests (and fixing computer problems). Along the way, I noticed something about
the renders that has nothing to do with radiosity, but with antialiasing.

To put it a simple way: When image pixels go over <1,1,1> in brightness
(regardless of how), antialiasing starts to fail, both in the on-screen preview
and in the saved image file. There also appear to be problems with just 'pure'
colors like <1,0,0> when elevated to, say, <10,1,1>. I've included an image of
various experiments. It's not an effect that immediately begins past <1,1,1> but
comes in gradually. So far, I have not seen this effect mentioned in the
documentation. I don't think the failed AA is simply the result of a difference
in contrast/brightness with surrounding darker pixels.

[Currently, I'm running a POV-ray v3.8 development build in Windows, with the
newer AA Sampling_Method=3 and Stochastic_Seed; but I also tried the typical
method 2, with the same results. Perhaps there is a way to reduce or eliminate
the 'missing AA' with better settings?]

Of course, this lack of AA would probably not show up in most normally-lit
POV-ray scenes, where light_sources and object textures are 'balanced' correctly
and result in pixels that don't exceed <1,1,1>. (Otherwise, it would simply be
'bad lighting'.) But the lack of AA can be very obvious in pure radiosity
scenes, when a light-emitting object is visible -- like a bright lightbulb for
example, that needs its finish{emission} value increased for effect.

In more detail: Since antialiasing involves shooting many rays into a scene per
pixel (rather than just one ray), then averaging(?) them to get a smooth result,
it seems that the color/lighting computations for that pixel should be clamped
at a maximum of <1,1,1> *before* the averaging is done. I don't know the inner
workings of the antialiasing mechanism, so this is just my guess. For example,
when a white object's pixel brightness is created by, say, emission 10, it
should be automatically reduced to <1,1,1> before the AA 'averaging' scheme
kicks in-- since 'white is white', and a typical low-dynamic-range 24-bit image
can only reproduce pure white as <1,1,1> anyway, not <10,10,10>.

There *is* a simplistic way of correcting this in pure radiosity scenes-- at
least in certain circumstances-- by making two identical objects, one invisible
with the high required emission value, and one that's visible but with an
emission value of 1.0 (and a no_radiosity flag). But this scheme could get
cumbersome.

I don't know how antialiasing treats global lighting from a HDR image (like a
HDR skydome), where the emitting pixels in the image can be far brighter than
<1,1,1>. If those pixels are actually visible in the scene, or are reflected in
a scene's mirrored sphere, perhaps the same AA problem occurs(?)

Post a reply to this message

Attachments:
Download 'antialias_problem_with_bright_objects.png' (706 KB)

Preview of image 'antialias_problem_with_bright_objects.png'