On Sun, 12 Jul 1998 23:41:05 +0200, Thorsten Froehlich 
      <Tho### [at] compuservecom> wrote:
>Fran wrote:
>>The last bit about the non-linear transformations....
>>
>>Don't have any idea how to do this but something like
>>
>>matrix {
>>    <formula,formula,formula>
>>
>>etc
>>
>>Sorta like a translation matrix.
>
>I am not sure, but a matrix may not work. I would try to deform the *RAY*, 
>not the object. This is the suggested method in "An introduction to ray 
>tracing", page 115 - "Deformed surfaces".

Right, matrices won't work.  By definition, anything that can be represented
as a matrix is linear.  But Fran wasn't talking about what mathematicians 
traditionally call a matrix; he was talking about a notational system that
superficially resembles the one POV now uses for linear transformations.

POV now works by deforming the ray, and this works fine for invertible linear 
transformations, because a ray is still a ray after transformation.  With a 
nonlinear transformation, though, assuming you can even figure out how to 
invert it, the ray would end up being a curve of some type.  A number of 
objects already require the raytracer to solve a nasty polynomial to find the 
intersection with a straight line.  In general, the problem of intersection 
with an arbitrary curve might be so difficult as to be practically 
impossible.  Still, it might be possible to work with perspective 
transformations, because they also map lines to lines. They aren't always
invertible, though, so you'd have a problem with a ray that intersected such 
a surface at a singularity.  That's why zero is an illegal value in a scale.

The problem of general nonlinear transformations would likely only be solved 
by converting the object to a mesh and then using the forward transform on 
its constituent elements, but unless the inverse transform is easily 
calculable, I don't see how you could transform the texture as well.  

This brings us back to the problem of making a mesh from arbitrary objects,
which would be really, really nice but perhaps not terribly easy.  If we had
it, though, we could do a lot of other neato things we can't now, like real 
radiosity, conversions from POV to other formats like VRML, OpenGL preview,
and displacement mapping.  The object orientation of POV means that it could
have each object be responsible for its own mesh generation, and at least in
the short term it could just punt to an error message for objects that don't
know how to do so, just as POV does now for the insideness test on meshes.
Objects that might require this treatment are the polynomial surfaces.

If we wanted something useful, though, the bare minimum would be for CSG
operations to be able to do mesh generation by working with the meshes 
generated by sub-objects.  To me, this seems like the difficult part of the
job.

Post a reply to this message