Christoph Hormann wrote:

>> To phrase it again in a way that does not require a technical background
>> to understand:  Implementing a very basic support for the concept of
>> mip-mapping in a raytracer that can be used in practical applications
>> would be so much work and would introduce so much bloat to the source
>> code in form of special case handling and making additional data
>> available that is not needed or even generated in normal raytracing that
>> i seriously doubt it will be implemented in POV-Ray.


  Where exactly would that difficulty be? Can you be more specific?

  I disagree with that statement.
  The only thing that trilinear interpolation would need is to
calculate mipmaps from image maps (when requested), which is
extremely trivial to do (and only needs 1/3 of additional memory),
and at trace time to know the sum of ray lengths so far as well as
the distance between image pixels, which is very trivial too.
Calculating trilinear interpolation from these values is very easy.

  "It doesn't work correctly with reflections/refractions from
curved surfaces" is actually not a reason to not to implement those
simple steps I described above. There are tons of images out there
which do not need reflections/refractions to work correctly (or at
all). There are tons of mesh-based imagemapped scenes out there
which would greatly benefit from trilinear interpolation.

  If in a certain scene the trilinear interpolation looks annoyingly
bad in a certain reflection or refraction, the interpolation can be
turned off and you'll get what POV-Ray currently renders. What's the
problem? If you don't like it, you are not forced to use it.

  (In a more versatile implementation you could turn interpolation
of textures hit by reflected/refracted rays on a per-object basis.)

-- 
                                                          - Warp

Post a reply to this message