> Exactly what would happen if you rendered the image at a large  
resolution
> and then scaled it down. You get smooth results. If your very bright stars
> covered several pixels each, they would be completely jaggy using your
> method. To me that's not intuitive when I have turned on AA to get smooth
> results.


I assume, you can get this result with P3.5, if you:

1) Scale the brightness of all lights/textures to fit into [0,1]
2) Render the image with an n-times higher resolution, using 16Bit
3) Rescale the image to the size, you want ...
4) make the brighness-adjustment of 1) reverse ...

this should avoid the "unwanted" clipping ...
And I think, this is what should happen, when using bright pigments ...

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c7924be@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> >   So you prefer to have a white sphere which doesn't look antialiased at
all?
>
> Yes.
> Well, not precisely...a plain rgb 1 sphere with normal levels of
> lighting will render fine. But an object twice as bright should
> influence a pixel twice as much. You can work around a rgb 10 sphere not
> looking antialiased, you can't work around the values being clipped.

Having superbright objects influence their surroundings more than others
would mean, I believe, that ultrabright (>100?) objects would influence
larger and larger areas of the screen, which is not possible with the
current method.

Hmm, talking about color, how's this for an idea (warning: this is
tangential to the thread): store all image data as 64bit integers, with the
range 0-1 fitting in 24 or 32 bits.  Then, adjust the overall brightness of
the scene based on the brightest object?

...Chambers


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

> If you really wanted to, you could make each star between 1/2 - 3 pixels  
on
> a 640x480 screen, and use media-filled spheres instead of plain white dots,
> to give a nice glowing effect that wouldn't look bad on higher resolutions

that _IS_ cheating ...
... just to have the AA work the way you want ...

Post a reply to this message

In article <3c7931d6@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Having superbright objects influence their surroundings more than others
> would mean, I believe, that ultrabright (>100?) objects would influence
> larger and larger areas of the screen, which is not possible with the
> current method.

Not at all. It will only influence a pixel which covers the object.


> Hmm, talking about color, how's this for an idea (warning: this is
> tangential to the thread): store all image data as 64bit integers, with the
> range 0-1 fitting in 24 or 32 bits.  Then, adjust the overall brightness of
> the scene based on the brightest object?

The brightness is already stored as single-precision floats, I don't see 
where this would help. And scaling the colors so the brightest object is 
rgb 1 won't work very well...it is too linear, and you will end up with 
some objects being white and everything else being nearly black. And 
antialiasing will still wipe out small details.
The clipping will eventually need to be done, because monitors have a 
finite dynamic range, but it shouldn't be done before antialiasing in my 
opinion. Really, there should be a way to output more accurate colors to 
the final image file, there are a few formats designed for this.
A smarter antialiasing scheme should be possible, which would soften 
jagged edges but leave points and small details alone.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c792f95@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> No matter how many "superbright" stars you have, you will have many ~more~
> dark sky samples.  The answer is not to make the stars brighter, but to make
> them bigger.  Have them cover at least a pixel.

That just doesn't look good at ordinary resolutions. The result only 
slightly resembles stars. If the values were unclipped, you could make 
sure that the stars were sub-pixel at all but extremely high 
resolutions, but crank up their brightness.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> Not at all. It will only influence a pixel which covers the object.

  This depends on whether we want a "mathematically correct" image or
if we want to simulate photography.
  In photography a really bright object will "bleed" in the image, and its
influence can extend considerably outside its real boundaries.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
> Yep ...
> But IIRC it will get AA'ed if samples are taken long enough ...

  I don't think so.
  If the border of the bright object takes one half of the current pixel,
about a half of the samples will hit the object. If the object contributes
10 times more than the other half of the pixel, it will dominate the color
of the pixel with a factor of 10:1 (which means that the other half of
the pixel can diminish the color of the pixel only by 1/10, even though
its area is 1/2 of the pixel).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

>   I don't think so.
>   If the border of the bright object takes one half of the current pixel,
> about a half of the samples will hit the object. If the object contributes
> 10 times more than the other half of the pixel, it will dominate the color
> of the pixel with a factor of 10:1 (which means that the other half of
> the pixel can diminish the color of the pixel only by 1/10, even though
> its area is 1/2 of the pixel).

It will give a solution (nearly)equal to

http://news.povray.org/8JTVb%2BOd4xB%40lzer.net

which is IMO the way AA should work ...
at least I would like to hava a switch, controlling this behaviour ...
You can also use the Jitter to select the set of points, which contribute  
to the pixel ... set it to sqrt(2) and you should have a fairly good AA- 
effect ... (if only I could hack a POV-Patch ...)

Remember: Clipping means loosing information ... We should throw away this
information only if we have finished processing the image ...
Don't argue with: "AA also means loosing Information" ...

true, but AA is what we want ...
But we (at least me) don't really want clipping... we just use it, because  
of the limits of our graphics-hardware and fileformats ...

I wished my monitor could present pixels in a color of <1024,1024,1024>,  
when <255,255,255> is normal white ...

Is there any way to convince you ?

BTW: if the behaviour would have any chance of beeing changed, consider,  
for the sake of consistency, to do this as well for negative values, not  
only for positves ...
so a 50%-AA combination of <10,1,0> and <0,-10,0> would give <1,0,0> after  
clipping and not <0.5,0.5,0>

Post a reply to this message

In article <3c7941af@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   This depends on whether we want a "mathematically correct" image or
> if we want to simulate photography.
>   In photography a really bright object will "bleed" in the image, and its
> influence can extend considerably outside its real boundaries.

That's not what antialiasing is for...it is to counteract aliasing.

Such a glow effect would still be useful, and would pretty much have to 
be built-in unless POV is patched to output a high dynamic range format. 
One possibility is to make it part of a post-processing stage, similar 
in purpose to the MegaPOV patch but more flexible. (if such a 
post_process stage is available, it would be simple to add a filter to 
soften the edges of bright objects...people would probably just use the 
glow filter though)
(MegaPOV has a glow filter, but I don't think it does the exact same 
thing)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" wrote:
> That's not what antialiasing is for...it is to counteract aliasing.

But what if you have a pattern with two colors - black and an extremely
bright white - and the pattern is aliased... What will your version of
antialiasing do about it? Nothing!

Let's repeat the message: We have antialiasing to counteract aliasing. That
is what it should do.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message