Hi,

does anyone know a compile/patch for pov that supports MIP-mapping for
image-maps or other types of interpolation than bilinear (bicubic would be
nice).
Or the other way round: Is there a reason for mip-mapping isn't supported (I
think every $100 graphics card can do it ;-)

thanks
-sascha

Post a reply to this message

Sascha Ledinsky wrote:

> Hi,
> 
> does anyone know a compile/patch for pov that supports MIP-mapping for
> image-maps or other types of interpolation than bilinear (bicubic would be
> nice).
> Or the other way round: Is there a reason for mip-mapping isn't supported (I
> think every $100 graphics card can do it ;-)


So far, I can only think of one reason: a single pov's ray has no area 
at the intersection.

Using Mip-mapping required to know that area or the four corners of the 
pixel/ray, in order to have the right depth for mip-mapping... 
(sidenote, there might be an additional problem when "once" is not used 
and there is multiple instance of images involved.)


A graphic card can use mip-mapping because it can use 'boxed rays' (but 
they won't do that with reflection on silly surface (only triangles and 
other flat poly) and neither with refraction).

Povray's ray are not that kind of rays.

It might be possible if the code was changed (heavily) so that instead 
of tracing a ray from the camera, an area (a full pixel, defined by 4 
rays) was traced from the camera. But it may generate more problems for 
other things...

Post a reply to this message

On Thu, 10 Oct 2002 16:39:58 +0200, "Sascha Ledinsky" <sas### [at] opensyscoat>
wrote:
> does anyone know a compile/patch for pov that supports MIP-mapping for
> image-maps or other types of interpolation than bilinear (bicubic would be
> nice).

Other types of interpolation you can find in density patch by R.Suzuki
http://abx.art.pl/pov/patches/patches.php?Author=R.Suzuki

> Or the other way round: Is there a reason for mip-mapping isn't supported (I
> think every $100 graphics card can do it ;-)

Becouse POV-Ray is not a graphics card ?

ABX

Post a reply to this message

"Le Forgeron" <jgr### [at] freefr> wrote in message
news:3DA### [at] freefr...

> It might be possible if the code was changed (heavily) so that instead
> of tracing a ray from the camera, an area (a full pixel, defined by 4
> rays) was traced from the camera. But it may generate more problems for
> other things...

I did a google and found a method for mip mapping in a raytracer here
http://www.cs.unc.edu/~awilson/class/238/#challenges
I'm not a programmer and don't even know povs internals, but I can image
that it might need heavy code changes...
But anyway, thanks for your answer, it now makes a lot more sense to me!

Is this also the reason why derivates are not supperted in POVMANs version
of shader-language?

Post a reply to this message

In article <3da59141$1@news.povray.org> , "Sascha Ledinsky" 
<sas### [at] opensyscoat> wrote:

> does anyone know a compile/patch for pov that supports MIP-mapping for
> image-maps or other types of interpolation than bilinear (bicubic would be
> nice).
> Or the other way round: Is there a reason for mip-mapping isn't supported (I
> think every $100 graphics card can do it ;-)

Because mip-mapping is pointless for a ray-tracer?  In essence the only need
for mip-mapping is to reduce artifacts when there is no anti-aliasing or
anti-aliasing is very hard to do and interpolation of the image is out of
the question as well.  This is the case for Z-buffer based renderers like
your $100 graphics card, but not for POV-Ray.  The gain from using
mip-mapping in POV-Ray would be zero as far as quality is concerned.

    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

Sascha Ledinsky wrote:

> Is this also the reason why derivates are not supperted in POVMANs version
> of shader-language?
> 
No, true reason is my laziness :-)
But talking more seriously: Yes, this is one of reasons, why derivatives 
are not supported in POVMan: current implementation lacks information to 
support it. I have intention to provide some support for surface 
derivatives (for these objects, which support uv-mapping, although 
meshes are probably the only types, for which this uv-mapping is 
useful), but haven't had enough time for it :-(
I thought also about mip-mapping (or filtering of texture image file, as 
it is in RenderMan (BMRT) renderers), but this could be done only after 
surface derivatives are implemented. And I'm not quite sure, that this 
feature will make big difference with current supersampling (as Thorsten 
pointed out).

Post a reply to this message

I disagree.  I think mip-mapping would be quite useful in a ray tracer.
Mip-mapping is a computationally cheap way to achieve great texture
anti-aliasing results.  In many situations, you'd need to shoot tons of AA
rays to achieve the same effect as mip-mapping.

The problem with applying mip-mapping to ray-tracing is that it requires the
knowledge of the ray differential.  With normal scan-line rendering, this is
easy to compute using perspective transformations.  However, in a ray tracer
it is much more difficult because rays can be reflected and refracted from
either flat or curved surfaces.

Check out this paper for a more in-depth discussion of mip-mapping and ray
differentials in the context of ray tracing:
http://graphics.stanford.edu/papers/trd/

-Nathan


"Thorsten Froehlich" <tho### [at] trfde> wrote...
> In article <3da59141$1@news.povray.org> , "Sascha Ledinsky"
> <sas### [at] opensyscoat> wrote:
>
> > does anyone know a compile/patch for pov that supports MIP-mapping for
> > image-maps or other types of interpolation than bilinear (bicubic would
be
> > nice).
> > Or the other way round: Is there a reason for mip-mapping isn't
supported (I
> > think every $100 graphics card can do it ;-)
>
> Because mip-mapping is pointless for a ray-tracer?  In essence the only
need
> for mip-mapping is to reduce artifacts when there is no anti-aliasing or
> anti-aliasing is very hard to do and interpolation of the image is out of
> the question as well.  This is the case for Z-buffer based renderers like
> your $100 graphics card, but not for POV-Ray.  The gain from using
> mip-mapping in POV-Ray would be zero as far as quality is concerned.
>
>     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

Nathan Kopp <pov### [at] nkoppmailshellcom> wrote:
> I disagree.  I think mip-mapping would be quite useful in a ray tracer.
> Mip-mapping is a computationally cheap way to achieve great texture
> anti-aliasing results.  In many situations, you'd need to shoot tons of AA
> rays to achieve the same effect as mip-mapping.

  Another place where mipmapping is really useful is, of course, where
it's usually used, ie. in mapping an image onto a surface. Scanline
renderers invariably support this and it affects the quality of the
texture when the pixels of the image map (texels) are smaller than the
pixels of the rendered image.

  (Of course mipmapping has to be used in conjunction with trilinear
filtering, or else you'll get ugly and very visible transition lines
where the mipmap level changes, but this is a whole different story.
Another different story is that trilinear filtering is not perfect,
but to get a perfect result you need to use a more advanced algorithm
(I think it's called anisotropic filtering or something like that).)

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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3da5ae73@news.povray.org...

>This is the case for Z-buffer based renderers like your $100 graphics card,
but not for POV-Ray.

I don't wanted to offend anyone by comparing povray with a  $100 graphics
card, sorry for that ;-)
Pov is a great renderer, I've tried many other free renderers like radiance,
bmrt, and 3delight but still pov is my favorite and has many features the
other programs don't have.
The thing I wanted to point out is that under certain conditions (env-maps
instead of true reflection for example) scanline renderes produce better
results than povray in less time.

>The gain from using mip-mapping in POV-Ray would be zero as far as quality
is concerned.

Of course povray can still make better images by using a high level of
supersampling, so you're right as far as quality is concerned, but I think
other methods than supersamling could save a lot of render time and still
produce high quality antialised images...

-sascha

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3da5ae73@news.povray.org...
> In article <3da59141$1@news.povray.org> , "Sascha Ledinsky"
> <sas### [at] opensyscoat> wrote:
>
> > does anyone know a compile/patch for pov that supports MIP-mapping for
> > image-maps or other types of interpolation than bilinear (bicubic would
be
> > nice).
> > Or the other way round: Is there a reason for mip-mapping isn't
supported (I
> > think every $100 graphics card can do it ;-)
>
> Because mip-mapping is pointless for a ray-tracer?  In essence the only
need
> for mip-mapping is to reduce artifacts when there is no anti-aliasing or
> anti-aliasing is very hard to do and interpolation of the image is out of
> the question as well.  This is the case for Z-buffer based renderers like
> your $100 graphics card, but not for POV-Ray.  The gain from using
> mip-mapping in POV-Ray would be zero as far as quality is concerned.
>
>     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