Hello

I am experimenting with new antialiasing methods for povray. Now I am 
looking for scenes where the current methods do a poor job or need too many 
samples/pixels to produce a nice result. If you have such a scene which is 
not too large (<100kB) and does not take hours to render please send it to 
me (mri### [at] gmxnet) or post it to p.*.sf. I will then test if my new 
implementations do better than the old ones.

- Micha

Post a reply to this message

Micha Riser wrote:
> If you have such a scene which is > not too large (<100kB) and
> does not take hours to render

camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:
> ...
> camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}
> ...

LOL! That small enough for you? ;)

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3C7451CE.B8970CD3@engineer.com...
> Micha Riser wrote:
> > If you have such a scene which is > not too large (<100kB) and
> > does not take hours to render
>
> camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}
>
>

I think you left out the reflective sphere there ;o)

--
#local X=20*<-2,2,5>;#local K=2*z*X-X;#local R=seed(frame_number);blob{#while(K
.x>X.x)#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X
-N);sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{
emission<2,4,5>*5}}hollow scale.05}//   http://nekar_xenos.tripod.com/metanoia/
sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<8,-8>1<8,8>1<8,8>1
translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9,18>][1rgb 0]}}}


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.325 / Virus Database: 182 - Release Date: 2002/02/19

Post a reply to this message

Kari Kivisalo <ray### [at] engineercom> wrote:
: camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}

  The problem with this kind of scene is that the farther away we go to
the "horizon", the more checkers will fit inside a single pixel. This means
that the farther away we go, the more samples we would need. When we are far
enough, no amount of samples is enough.

  For pigments there's one trick that can be used: trilinearly-filtered
mipmapping. However, this has two problems:
  1. I don't know how mipmaping could be implemented in *procedural* textures
(without taking exorbitant amounts of memory and without losing details).
  2. It works only for the texture of one object. If the checkers were
actual objects (eg. boxes or whatever), this trick won't work.

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

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

>   For pigments there's one trick that can be used: trilinearly-filtered
> mipmapping.

No, it won't help.  Mipmapping just moves the problem to a preprocessing stage
and in general is nearly pointless for raytracing.  Still exactly the same
problem needs to be solved, but can of course use more processing intensive
algorithms for interpolation.  That is why it is used in the first place in
one application:  To allow real-time display in a reasonable quality in CAD
previews (and today games).


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

>   For pigments there's one trick that can be used: trilinearly-filtered
> mipmapping. However, this has two problems:
>   1. I don't know how mipmaping could be implemented in *procedural* textures
> (without taking exorbitant amounts of memory and without losing details).
>   2. It works only for the texture of one object. If the checkers were
> actual objects (eg. boxes or whatever), this trick won't work.

Not mipmapping, but similar ideas:
Basically, you have to compute the color of an area of texture, not just 
one point.

1: Use distance-based blurring on the texture. Beyond a certain 
distance, start blurring, and blur more with more distance. Breaks if 
you zoom in too much or have an object that magnifies the scene behind 
it, and is slow.

2: Use distance-based patterns. The ordinary checker pattern closer up, 
but with distance the values get closer to 0.5, and it becomes a blend 
instead of a block pattern. Same problems as above, but faster. Also, it 
will break for more complex color maps, and requires extra work on the 
patterns.

3: Take the first object the pixel hits, and supersample it based on 
distance, distant objects getting more samples. You could leave out the 
other scene objects for speed...if they weren't the first intersection, 
it is unlikely they will have much contribution to the pixel. Probably 
the easiest to implement, though not necessarily fast.

4: Use the ray footprint. Figure out the area the pixel covers when 
projected out to the intersection point, and use one of the above two 
techniques to compute the color. One possible way to do this would be to 
fire a pair of slightly different rays (or maybe 3 rays?) and calculate 
the angle between them. The only disadvantage this would have would be 
speed.

All of these would be better if they were done on a per-object basis, 
for speed.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, it won't help.  Mipmapping just moves the problem to a preprocessing stage
> and in general is nearly pointless for raytracing. 

  If it works in scanline rendering, it can work in the exact same way in
raytracing.
  But I already mentioned the difficulties in this. The main difficulty is
that it can be used almost exclusively for image maps.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> Basically, you have to compute the color of an area of texture, not just
> one point.
>
> 1: Use distance-based blurring on the texture. Beyond a certain
[....]
> techniques to compute the color. One possible way to do this would be to
> fire a pair of slightly different rays (or maybe 3 rays?) and calculate
> the angle between them. The only disadvantage this would have would be
> speed.

You know, you can always construct scenes (intentionally), that will breake
this algo ...

I would simply try to create _VERY_ small structures...
either I will produce still moires or your algo would be simply inaccurate
...

basically you wil always have problems, with scenes that produce
moire-patterns ...

Post a reply to this message

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

>> No, it won't help.  Mipmapping just moves the problem to a preprocessing
>> stage and in general is nearly pointless for raytracing.
>
>   If it works in scanline rendering, it can work in the exact same way in
> raytracing.

I did not say it can't work, I said it is pointless.  How do you think the
mipmaps are created?  What kind of "more advanced" interpolation does a paint
program use/support that will increase quality compared to POV-Ray image map
interpolation and adaptive antialiasing?  The answer is that there is no such
interpolation algorithm...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thanks to the ones who submitted scenes.

There are first test results of my new implemenations compared to the old 
ones:

See http://www.povworld.org/povray/aatest.html . Note that the servers 
bandwith is quite limited.

- Micha

Post a reply to this message

In article <3c73fc36@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I am experimenting with new antialiasing methods for povray. Now I am 
> looking for scenes where the current methods do a poor job or need too many 
> samples/pixels to produce a nice result. If you have such a scene which is 
> not too large (<100kB) and does not take hours to render please send it to 
> me (mri### [at] gmxnet) or post it to p.*.sf. I will then test if my new 
> implementations do better than the old ones.

BTW, looking through the old Ray Tracing News archives, there's plenty 
of information about this...one interesting method was to make a hash 
value from the objects intersected and shadow rays. If the hash value 
changed from one pixel to another, either the set of objects hit 
changed, or the image passed into/out of shadow. Then the colors were 
compared, and the pixel was only antialiased if the hash changed and the 
color was different. No antialiasing the tail of a black cat on a 
moonless night, but only object/shadow edges were antialiased. Sharp 
edges in the texture were left alone...these guys apparently didn't use 
textures with sharp edges. ;-)
This technique could be adapted to POV as a way of specifying different 
antialiasing parameters for object edges and textures...if the hash 
value triggers it, use one setting, but if the color difference is 
greater than a threshold (and the hash values are the same), use a 
different setting. If it could be further controlled...certain textures 
or objects using no antialiasing...it could make things like starfields 
much easier.

This reminds me...are the colors clipped before or after antialiasing? 
It should be after...a "superbright" object (rgb > 1) should contribute 
more to a pixel than a dim (rgb 1) one.

-- 
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 <3c73fc36@news.povray.org>, Micha Riser <mri### [at] gmxnet>
> wrote:
> This reminds me...are the colors clipped before or after antialiasing?
> It should be after...a "superbright" object (rgb > 1) should contribute
> more to a pixel than a dim (rgb 1) one.

IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

Post a reply to this message

> See http://www.povworld.org/povray/aatest.html . Note that the servers
> bandwith is quite limited.

So what can we conclude ?

1. These Scenes _are_ hard nuts for AA
2. Your method _CAN_ improve the visual quality by taking not to much  
samples ... (under circumstances)
2'. But it can also be that it makes the result even worse ...
2". The result depends on the choosen AA-Method; There's no "Best-Of" ...
3. POV Raytracing works in a diskreet world where it's hard to simulate  
the continueity of the pure math ...
... leading to:
4. proving (of course, not a mathiematical proove) right, with my former  
statement, that every known AA-Algo can be broken with a scene ...

... at least if you consider the resolution to be independend ...


BUT: Good work ... I think we needed something like that ...

Post a reply to this message

Christopher James Huff wrote:

> BTW, looking through the old Ray Tracing News archives, there's plenty
> of information about this...one interesting method was to make a hash
> value from the objects intersected and shadow rays. If the hash value
> changed from one pixel to another, either the set of objects hit
> changed, or the image passed into/out of shadow. Then the colors were
> compared, and the pixel was only antialiased if the hash changed and the
> color was different. No antialiasing the tail of a black cat on a
> moonless night, but only object/shadow edges were antialiased. Sharp
> edges in the texture were left alone...these guys apparently didn't use
> textures with sharp edges. ;-)

I do not like the idea of antialiasing only at objects frontiers.. as 
textures are certainly one of the most important thing with POV-Ray.

> This technique could be adapted to POV as a way of specifying different
> antialiasing parameters for object edges and textures...if the hash
> value triggers it, use one setting, but if the color difference is
> greater than a threshold (and the hash values are the same), use a
> different setting. If it could be further controlled...certain textures
> or objects using no antialiasing...it could make things like starfields
> much easier.

I do not know the povray source good enough for adding object specific 
features :(.

> This reminds me...are the colors clipped before or after antialiasing?
> It should be after...a "superbright" object (rgb > 1) should contribute
> more to a pixel than a dim (rgb 1) one.

I will look this up.

- Micha

Post a reply to this message

Jan Walzer wrote:

>> See http://www.povworld.org/povray/aatest.html . Note that the servers
>> bandwith is quite limited.
> 
> So what can we conclude ?
> 
> 1. These Scenes _are_ hard nuts for AA

Sure.

> 2. Your method _CAN_ improve the visual quality by taking not to much
> samples ... (under circumstances)
> 2'. But it can also be that it makes the result even worse ...

Well, my method is based on method 2, that is also adaptive. If you compare 
it with the standart method 2, my new implementations do always equally or 
better. (sure one could contruct a scene where this is not the case)

> 2". The result depends on the choosen AA-Method; There's no "Best-Of" ...

I have been a bit surprised how god method 1 actually performed.. as it is 
really simple.

> 3. POV Raytracing works in a diskreet world where it's hard to simulate
> the continueity of the pure math ...
> ... leading to:
> 4. proving (of course, not a mathiematical proove) right, with my former
> statement, that every known AA-Algo can be broken with a scene ...
> 
> ... at least if you consider the resolution to be independend ...

This is certainly true.. but the worst case scenario is here certainly not 
allowed to be the criterion.

> 
> 
> BUT: Good work ... I think we needed something like that ...

Thanks.

Post a reply to this message

"Christopher James Huff" wrote:
> This reminds me...are the colors clipped before or
> after antialiasing?
> It should be after...a "superbright" object (rgb > 1)
> should contribute more to a pixel than a dim (rgb 1) one.

It is clipped before AA and there's a good reason.

Suppose you have a really bright sphere (the sun). All pixels that hit the
sun would be completely white no matter if the sun occupies a small or big
amount of the pixel, simply because the high brightness would dominate in
the average. The result would be that very bright objects would not look
antialiased at all no matter how high quality AA settings you used.

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

I'll be looking at this more closely tommorow. What little I see is very
promising. Thanks for taking my proposal seriously Micha! This should be
perfect for the next MegaPOV. :-D

Post a reply to this message

In article <3c782d3c@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> It is clipped before AA and there's a good reason.
> 
> Suppose you have a really bright sphere (the sun). All pixels that hit the
> sun would be completely white no matter if the sun occupies a small or big
> amount of the pixel, simply because the high brightness would dominate in
> the average. The result would be that very bright objects would not look
> antialiased at all no matter how high quality AA settings you used.

Well, this explains why I never succeeded in getting stars to survive AA 
by increasing their brightness...that was the exact effect I expected 
and wanted. I can manually soften the sun's outline (media, or a dimmer 
sphere visible just around its edges), eliminating the problem there, 
but there doesn't seem to be any way to compensate for small 
(sub-pixel), very bright objects getting obliterated by the antialiasing.
Maybe a smarter algorithm would be possible...if there are other 
high-brightness pixels nearby, you are at the edge of a bright object, 
so clip and supersample, otherwise supersample then clip.

-- 
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 <8JP### [at] lzernet>, jan### [at] lzernet (Jan Walzer) wrote:

> 4. proving (of course, not a mathiematical proove) right, with my former  
> statement, that every known AA-Algo can be broken with a scene ...

Just use an infinite number of samples per pixel. I don't have the CPU 
power to test this though, ask God. ;-)
Actually, that might not be enough, because you still have the grid of 
pixels...how about creating a neural net to detect the moire patterns 
and compensate for them?
Or just reduce the pixel size to near-microscopic. Then you won't even 
need antialiasing. ;-)
Really, I think resolutions are going to make a jump soon, so 
antialiasing won't be as big a requirement.

-- 
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:
> Maybe a smarter algorithm would be possible...if
> there are other high-brightness pixels nearby,
> you are at the edge of a bright object, so clip
> and supersample, otherwise supersample then clip.

I have had similar considerations, but have not managed to get any further
than wondering what method could be used. I don't think it will be trivial,
and there'll always be cases where you get an opposite behavior of what you
want.

If a smart behavior isn't possible, I prefer the current one. The current
method works the same way as if you rendered the image at huge resolution
and then scaled it down.

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

Jan Walzer wrote:
> 
> > This reminds me...are the colors clipped before or after antialiasing?
> > It should be after...a "superbright" object (rgb > 1) should contribute
> > more to a pixel than a dim (rgb 1) one.
> 
> IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
same image for both cases. The colors are clipped before aa
and DOF calculations :(


_____________
Kari Kivisalo

Post a reply to this message

Rune wrote:
>
> It is clipped before AA and there's a good reason.

It's not realistic.


_____________
Kari Kivisalo

Post a reply to this message

"Kari Kivisalo" wrote:
> Rune wrote:
> >
> > It is clipped before AA and there's a good reason.
>
> It's not realistic.

You can't talk about realistic. AA doesn't happen in nature... ;)

The current AA give the same result as if you rendered the image at a very
large resolution and then scaled it down. I think that's what AA is meant to
do. It gives smooth results. the way you'd like it to work, it wouldn't
always give smooth results, often things would look like they had not been
antialiased at all.

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

Rune wrote:
>
> You can't talk about realistic. AA doesn't happen in nature... ;)

Take a picture either with a film or ccd camera of a 10 candela source.
Compare that to picture of a 1000 candela source with same exposure.
You say they would look the same.

We are making _digital_ images. Even digital images of nature have
been subject to aa or lpf at some point. In real life the clipping
occurs at the image detector/film, not before. The aa/lpf operates
on the unclipped intensities. Would be hard to make it work the other
way around :)


_____________
Kari Kivisalo

Post a reply to this message

Wow. I'm impressed. Your new methods look very good. Can you conduct a few
tests on more complete scenes? It would also be nice if you could explain
how you acheived each one so some more discussion about them can be had.

Post a reply to this message

Tony[B] wrote:

> Wow. I'm impressed. Your new methods look very good. Can you conduct a few
> tests on more complete scenes? It would also be nice if you could explain
> how you acheived each one so some more discussion about them can be had.

If you have a particular scene that you want to have tested you can send it 
to me and I will test it. I still want to do some modifications to my 
implementations. Once I have finished that I will make a detailed 
explanation how they work.

Post a reply to this message

"Kari Kivisalo" wrote:
> We are making _digital_ images. Even digital images of
> nature have been subject to aa or lpf at some point.

Photos are not subject to antialiasing I think. They are subject to focal
blur and probably other types of blurring that I don't know about. (Is that
what lpf mean?) But blurring has nothing to do with antialiasing. Blurring
(in nature) is resolution independent and covers many pixels, while
antialiasing is highly resolution dependent and has to do with individual
pixels.

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

OK. Cool. I'll see if I can find anything. I didn't have any specific one in
mind, I was just wondering how different a given scene would look.

Post a reply to this message

In article <3c78cad6$1@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> You can't talk about realistic. AA doesn't happen in nature... ;)

But it is intended to calculate a specific thing (the color over the 
entire pixel), and clipping makes that less accurate. And it apparently 
also happens with focal blur...not good!
I'd gladly take having unantialiased edges on superbright objects to 
have them work properly in other cases...I can work around the first 
problem by adding information to the scene, I can't work around the 
second (currently existing) problem. :-(
It also seems unintuitive to me: you have a bunch of small stars, and 
antialiasing wipes them out because they don't cover whole pixels. You 
make them brighter to compensate...nothing happens?!?
And with focal blur, the problem is worse...you simply will get a less 
realistic image.
Maybe some flag to limit the max value of a sample...radiosity uses 
similar tricks.


> The current AA give the same result as if you rendered the image at a 
> very large resolution and then scaled it down.

Not really...you could render to a format with a larger dynamic range, 
like RGBE, and process with tools that can handle it. ;-)

-- 
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 <3c782656@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I do not like the idea of antialiasing only at objects frontiers.. as 
> textures are certainly one of the most important thing with POV-Ray.

I wasn't suggesting that this be done. I was talking about a way of 
specifying different parameters for edge and texture AA.

-- 
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:
> Rune wrote:
> > You can't talk about realistic.
> > AA doesn't happen in nature... ;)
>
> But it is intended to calculate a specific thing
> (the color over the entire pixel), and clipping
> makes that less accurate.

No, it's a definition issue. The current definition of AA in POV-Ray is that
it is intended to calculate the average clipped color over the entire pixel
and it does that 100% accurately according to the definition.

If you want to change the definition, that can be discussed, but the current
behavior is not flawed or inaccurate in any way as it does exactly what it's
intended to do.

> And it apparently also happens with focal blur...not good!

I agree there. Focal blur is a completely different issue, and it should
take the unclipped colors as input. (And then we could get cool lens effects
without "cheating"!)

BTW, as I see AA and focal blur as two separate things, I think it should be
possible to use both at the same time (though it would be slow). I have
never understood why it's not possible.

> I'd gladly take having unantialiased edges on superbright
> objects to have them work properly in other cases...

But I wouldn't. I want my AA to smooth edges without exception. That's what
AA is for. To average colors is not the goal, it's just a mean to reach the
goal. The goal is smooth edges.

> It also seems unintuitive to me: you have a bunch of
> small stars, and antialiasing wipes them out because
> they don't cover whole pixels. You make them brighter
> to compensate...nothing happens?!?

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.

> And with focal blur, the problem is worse...you simply will
> get a less realistic image.

I agree.

> Maybe some flag to limit the max value of a sample...

You mean that the user should be able to change the value that samples are
clipped to, which is currently one? I wouldn't mind as long as the current
behavior keeps being the default.

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

Rune <run### [at] mobilixnetdk> wrote:
> BTW, as I see AA and focal blur as two separate things, I think it should be
> possible to use both at the same time (though it would be slow). I have
> never understood why it's not possible.

  It's probably possible, but thought to be unnecessary.
  (However, it might give a better result if the focal blur is giving a
grainy result no matter what variance values you are giving.)

-- 
#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 wrote:
>> IMHO it would be a _MAJOR_ design-flaw, if it wouldn't be this way ...

> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
> same image for both cases. The colors are clipped before aa
> and DOF calculations :(

/me doesn't like this ...

Post a reply to this message

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

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

Jan Walzer <jan### [at] lzernet> wrote:
>> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
>> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
>> same image for both cases. The colors are clipped before aa
>> and DOF calculations :(

> /me doesn't like this ...

  So you prefer to have a white sphere which doesn't look antialiased at all?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Rune wrote:
>
> Photos are not subject to antialiasing I think.

Digital (sampled) photos are. To sample correctly a signal
the sampling frequency must be at least twice the maximum
signal frequency. The signal must be Low Pass Filtered before
sampling or the high frequncy components will be aliased or
mirrored around 0.5*sampling frequency and appear as low
frequency interference in the sampled signal. The term aliasing
comes from this. High frequency components appear as low
frequency components.

> But blurring has nothing to do with antialiasing.

In ccd cameras the obvious choice for LPF would be to defocus
the lens. This blurring limits the spatial frequency and
prevents aliasing. So blurring _is_ antialiasing and operates
on the unclipped signal. The blurred signal is then sampled and
clipped at the detector.


_____________
Kari Kivisalo

Post a reply to this message

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.

-- 
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 in message
news:chr### [at] netplexaussieorg...
> In article <3c78cad6$1@news.povray.org>,
>  "Rune" <run### [at] mobilixnetdk> wrote:
>
> > You can't talk about realistic. AA doesn't happen in nature... ;)
>
> It also seems unintuitive to me: you have a bunch of small stars, and
> antialiasing wipes them out because they don't cover whole pixels.


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.

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

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

> Jan Walzer <jan### [at] lzernet> wrote:
>>> In beta 11 ambient sphere of rgb 1 and rgb 100 produce the exact same
>>> image when rendered with +am2 +a0.0 +j0.0. Also DOF produces
>>> same image for both cases. The colors are clipped before aa
>>> and DOF calculations :(

>> /me doesn't like this ...

>   So you prefer to have a white sphere which doesn't look antialiased at
> all?

Yep ...
But IIRC it will get AA'ed if samples are taken long enough ...
I, for myself, also use normally +J1 ... (OK ... this should be sqrt(2))

... so I assume there would be a way, to make it "soft" if one wants to  
...

Post a reply to this message

> 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