When you use image maps, you can tell povray to use bilinear filtering
when rendering it. This means that when the texels of the projection of the
image map on screen are bigger than the screen pixels, povray will calculate
the in-between pixels by interpolating the 4 nearby texels of the image map.
  This does a good job when the image map is zoomed so big that it's texels
are bigger than the screen pixels.
  However, when the texels are smaller than the screen pixels, the bilinear
interpolation doesn't help much. Not every texel of the image map will be
taken into account when rendering and so there will appear unwanted effects,
like broken lines, moire patterns, etc (even when antialiasing is on). They
don't look very good. The smaller the texels with respect to screen pixels,
the worse the result.
  In most 3D engines (renderers, 3D games, 3D video cards...) this problem
is corrected by calculating mipmapping and trilinear filtering.
  Mipmapping is the calculation of smaller versions of the same image map
with some algorithm (the simplest one would be calculating a 4 times smaller
image map by averaging 4 pixels of the original).
  The idea behind this is that when the image map is zoomed out so that its
texels would be smaller than the screen pixels, we switch to the smaller
version of the image map. The texels of this smaller version will be bigger
than the screen pixels, so bilinear filtering will still give a very good
result. When this one is small enough, we switch to an even smaller version,
and so on.
  This has the problem that the change between mipmaps is abrupt. If you
have a polygon so that one end is near the camera and the other end is
far away (like a floor), you will clearly see straight lines where the
mipmap changes.
  Trilinear filtering corrects this. Besides bilinear filtering, it also
interpolates between mipmaps so that instead of abrutply changing from one
mipmap to another at a certain distance, it smoothly interpolates between
them.
  The result is very good.

  Now, povray only supports bilinear filtering. How about adding automatic
mipmapping and trilinear filtering to 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

In article <382816f9@news.povray.org> , Nieminen Juha 
<war### [at] punarastascstutfi>  wrote:

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

I think the feature you want is anti-aliasing? :-)


    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

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


Go ahead, please, by all means, add it...

I suggest GamaSutra (I think you need to join). I'm sure you'll find plenty

http://www.gamasutra.com/features/19991027/deloura_01.htm

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote ...
> In article <382816f9@news.povray.org> , Nieminen Juha
> <war### [at] punarastascstutfi>  wrote:
>
> >   Now, povray only supports bilinear filtering. How about adding
automatic
> > mipmapping and trilinear filtering to it?
>
> I think the feature you want is anti-aliasing? :-)
>

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.

However, I think something more general than mipmapping (so that it works
with all kinds of textures instead of just imagemaps) would be better... I'm
just not sure how to do that.

-Nathan

Post a reply to this message

In article <3828efdc@news.povray.org> , "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> However, I think something more general than mipmapping (so that it works
> with all kinds of textures instead of just imagemaps) would be better... I'm
> just not sure how to do that.

Hmm, distance based recursive anti-aliasing should solve this problem -
determine the recursion level by the distance of the intersection.


    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

Hi Thorsten Froehlich, you recently wrote in
povray.unofficial.patches:

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

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

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