 |
 |
|
 |
|
 |
|  |
|  |
|
 |
From: Nieminen Juha
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 10 Nov 1999 09:15:33
Message: <38297e05@news.povray.org>
|
|
 |
|  |
|  |
|
 |
TonyB <ben### [at] panama phoenix net> 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
|
 |
|  |
|  |
|
 |
From: TonyB
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 10 Nov 1999 10:36:37
Message: <38299105@news.povray.org>
|
|
 |
|  |
|  |
|
 |
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
|
 |
|  |
|  |
|
 |
From: Thorsten Froehlich
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 10 Nov 1999 15:22:07
Message: <3829d3ef@news.povray.org>
|
|
 |
|  |
|  |
|
 |
In article <382### [at] 194 174 214 110> , lut### [at] stmuc com (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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
 |
|  |
|  |
|
 |
From: Thorsten Froehlich
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 10 Nov 1999 15:25:14
Message: <3829d4aa@news.povray.org>
|
|
 |
|  |
|  |
|
 |
In article <3828efdc@news.povray.org> , "Nathan Kopp" <Nat### [at] Kopp com>
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] trf de
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
|
 |
|  |
|  |
|
 |
From: Nieminen Juha
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 11 Nov 1999 04:41:39
Message: <382a8f53@news.povray.org>
|
|
 |
|  |
|  |
|
 |
Thorsten Froehlich <tho### [at] trf de> 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] punarastas cs tut fi> 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] ezwv com>
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] punarastas cs tut fi>]
| 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
|
 |
|  |
|  |
|
 |
From: Ron Parker
Subject: Re: Mipmapping and trilinear filtering in povray
Date: 24 Nov 1999 08:07:20
Message: <383be308@news.povray.org>
|
|
 |
|  |
|  |
|
 |
>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
|
 |
|  |
|  |
|
 |
|
 |
|  |