TonyB <ben### [at] panamaphoenixnet> wrote:
: Go ahead, please, by all means, add it...

  Actually my article was a request for someone else to do it... :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Did you check out the link? It's pretty cool. Gamasutra is a great site,

they manage to reduce the computations from 3978 adds and 8586 multiplies to
1506 adds and 1488 multiplies. I have no idea how useful this would be to
POV-Ray, however. I also found out where the Nintendo developers go to. =)

Post a reply to this message

In article <382### [at] 194174214110> , lut### [at] stmuccom (Lutz 
Kretzschmar) wrote:

>> Hmm, distance based recursive anti-aliasing should solve this problem -
>> determine the recursion level by the distance of the intersection.
>
> That is computationally much too expensive. Since the antialiasing has
> already been done by making a mipmap, it is not neccessary to fire
> extra rays. And once you start getting far away you would have to
> antialias far too many rays.

Yes, just for imagemaps. But that wasn't my point; it simply is a primitive
method that works with procedural textures as well.

My suggestion does of course not eliminate 'the missing a small object (or
texture detail) problem', it would only reduce it  by forcing a certain
recursion level depending on the distance (rather than only the threshold).

However, it is not difficult to construct a case (i.e. with a checker
pattern) that would easily break it - like all (recursive) antialiasing
based methods.


    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 <3828efdc@news.povray.org> , "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Unfortunately, anti-aliasing won't always fix the problem.  The primary
> difference is that with mipmapping, as the camera moves farther and farther
> away, more and more pixels are effectively averaged to produce the final
> output.  At the first stage, you get 4 pixels (2x2) averaged into 1.  The
> next stage might be 2x2 blocks of stage 1, meaning 4x4 of the original or 16
> total pixels.  By the time you get to stage three, its 2x2 of stage 2, or
> 8x8 of the original, or 64 pixles.  Getting that good of results by POV's
> current anti-aliasing techniques would really make things slow.

Hmm, for now a workaround migth be to use an external program to scale down
the image and use that as image map. Not a great workaround I have to admit,
but it will work (if Nieminen needs a workaround right now).


   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

TonyB wrote:
> 
> Did you check out the link? It's pretty cool. Gamasutra is a great site,

> they manage to reduce the computations from 3978 adds and 8586 multiplies to
> 1506 adds and 1488 multiplies. I have no idea how useful this would be to
> POV-Ray, however. I also found out where the Nintendo developers go to. =)

I discovered it several months ago.  It truly is a valuable resource on
several topics in graphics programming.

-Mark Gordon

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, for now a workaround migth be to use an external program to scale down
: the image and use that as image map. Not a great workaround I have to admit,
: but it will work (if Nieminen needs a workaround right now).

  But then the image map will not be detailed near the camera.
  And no, it's not a problem I'm currently having. It's just an idea.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 9 Nov 1999 07:43:37 -0500, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>  Now, povray only supports bilinear filtering. How about adding automatic
>mipmapping and trilinear filtering to it?

What about implementing bicubic interpolation, similiar to Photoshop?
That program seems to resize images very well.

Post a reply to this message

On Tue, 23 Nov 1999 10:20:59 -0500, Glen Berry <7no### [at] ezwvcom>
wrote:

>What about implementing bicubic interpolation, similiar to Photoshop?
>That program seems to resize images very well.

Bicubic interpolation is supported by POV. Check out "bitmap
modifiers" in the docs.


Peter Popov
ICQ: 15002700

Post a reply to this message

[On 9 Nov 1999 07:43:37 -0500, Nieminen Juha <war### [at] punarastascstutfi>]
|   However, when the texels are smaller than the screen pixels, the bilinear
| interpolation doesn't help much. 

True, that's why we have antialiasing.

| like broken lines, moire patterns, etc (even when antialiasing in on)

Not if used correctly. You should try the adaptive supersampling.

|   In most 3D engines (renderers, 3D games, 3D video cards...) this problem
| is corrected by calculating mipmapping and trilinear filtering.

True. But the reason they do this is because it's more convenient than
proper antialiasing like the one we have in POV-Ray, and it's easy to
implement in hardware. Also, trilinear filtering bring on other visual
artifacts. For instance, resolution drops in both directions when a
texture is viewed at an angle. Hardware tries to cope with this by
introducing so called anisotropic filtering, but that also has it's
limits.

In POV-Ray, supersampling can be used to correct any aliasingproblems
you may have, and it will work on any texture, not just image maps.

| The result is very good.

It pales in comparison with proper supersampling.

-- 
A penny for your thoughts.
Mine are more expensive.

Post a reply to this message

>In POV-Ray, supersampling can be used to correct any aliasingproblems
>you may have, and it will work on any texture, not just image maps.

Not really.  Textures should antialias themselves based on the "size" of
the ray hitting them, as well, if you want to avoid certain kinds of aliasing.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message