"Jan Walzer" <jan### [at] lzernet> wrote in message news:8JT### [at] lzernet...
> > 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 ...

But wouldn't it be cool to have several thousand media filled spheres added
to your scene? :)

...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

In article <3c79887d@news.povray.org>, run### [at] mobilixnetdk 
says...

> 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!

If somebody wants such a bright object in his scene, he'll need some kind 
glowing effect (wich will hide the aliasing) around it or it won't look 
right anyway.

Lutz-Peter

Post a reply to this message

"Lutz-Peter Hooge" wrote:
> If somebody wants such a bright object in his scene,
> he'll need some kind glowing effect

No he don't. I have made scenes with very bright object where I wanted
antialiasing but no glowing. I don't need glowing just because you say so.

> or it won't look right anyway.

You don't define what looks right or wrong. When bright objects glow it's
actually caused by focal blurring or something similar, but I have scenes
where I don't want such a glow. Things shouldn't glow unless I tell them to.

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

On Sun, 24 Feb 2002 17:54:40 +0100, Rune wrote:
> "Warp" wrote:
>>   It's probably possible, but thought to be unnecessary.
> 
> Yet it's a known fact that things very close to the focal point are jaggy.
> 
> And thinking about it, just like normally, the AA would only kick in where
> necessary, so using normal AA settings together with focal blur would
> probably only activate the AA on small amounts of the pixels, thus meaning
> that it wouldn't even be much slower. (It's logical, I just didn't realize
> it before.) I think it should be allowed. This is a feature request!

I think it's not allowed because the render loop for focal blur is a different
loop than the one for AA.  That's mostly historical, but it'd be hard to 
change.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

What focal blur work with animation? I haven't checked the povray source
code, but maybe it doesn't "remember" what rays it casted during the
tracing. If would put the exact data about what rays it's casted in a
buffer-like thing, with that buffer it should be possible to do
antialiasing. Same thing with animations. Saving that buffer to disk and
reusing it for the next frame should be able to prevent any jittering.

But maybe I'm completely wrong. I didn't try focal blur with animations that
much and I haven't checked povray's source code.

--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

["Apache" <apa### [at] yahoocom>]
| What focal blur work with animation? I haven't checked the povray source
| code, but maybe it doesn't "remember" what rays it casted during the
| tracing. If would put the exact data about what rays it's casted in a
| buffer-like thing, with that buffer it should be possible to do
| antialiasing. Same thing with animations. Saving that buffer to disk and
| reusing it for the next frame should be able to prevent any jittering.

Err. Jittering is optional. Simply don't use it in animation.

-- 
It's a dark day for mad science.

Post a reply to this message

I'm not talking about the jittering possibility available with +j, but about
the loose pixels that are visible when using focal blur. Don't those focal
blur pixels show a jitter-like behaviour when animating? If they do,
increasing the amount of focal blur samples will fix it anyways (needs more
processing time though).

Regards.
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

In article <3c863416$1@news.povray.org>,
 "Apache" <apa### [at] yahoocom> wrote:

> What focal blur work with animation? I haven't checked the povray source
> code, but maybe it doesn't "remember" what rays it casted during the
> tracing. If would put the exact data about what rays it's casted in a
> buffer-like thing, with that buffer it should be possible to do
> antialiasing. Same thing with animations. Saving that buffer to disk and
> reusing it for the next frame should be able to prevent any jittering.

This can't be done, because not only would it require a huge amount of 
memory, focal blur is adaptive. Since the scene being blurred changes, 
the blur samples need to change as well. You could just remove the 
adaptive capability, but that would be very slow. It should be possible 
to generate a list of random jitter vectors and use those for all pixels 
in every frame...the number of samples might vary, but most of the 
samples will be the same. This would give smoother results, actually, 
since the samples won't vary as much from pixel to pixel, though it 
might produce visible artifacts.
For now, you are pretty much stuck with using high enough settings that 
the grainyness isn't a problem.

-- 
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