Ron Parker wrote:
>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.

I am not sure I fully understand what you are refering to English isn't my native
language), can you expail this a little bit more, please?

Ron Parker wrote:
>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.

To keep it simple (and possibly not covering all cases) a quadartic function (for each
component of the vector) would be enough to make an egg out of a sphere.

Ron Parker wrote:
>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.  

Splines could be used so solve this problem as well, couldn't they?

Ron Parker wrote:
>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.

Yes, to generate meshes out of objects is an important feature missing. But I think it
is no (too big) problem to determine the surface of any polynomial defined object,
however I have never tried so I cannot claim this to be right.
But having a few million triangles and all their energies, etc. to calculate the
radiosity with a itterative approach (not to talk about a full matrix inversion) will
still not be easier or faster. And inorder to use raytracing with it you would have to
re-apply the light (energy) data to the objects as something like a texture. Or you
would only be able to render with radiosity and meshes. Not to talk about the
reflection problem (e.g. mirrors) which is still (???) there with radiosity based on
meshes.

Ron Parker wrote:
>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.

Yes, it is! Especially if you deal with more than one object it is hard to find out if
a specific part of an object (or to be more precise, the part of the objects mesh) is
to be displayed (and therefore a part of the surface), or not. I have tried to write a
program to do this (as a demo only - no real application!), but I ran exactly into
this problem. I have not done much more research to solve this because gettting the
Macintosh POV-Ray 3.1 beta ready was more urgent :-(  And other of the POV-Ray team
warned me that (my approach, like others) might not work. But I am still confident I
can get it to work if I spend more time with it!   Analysis is not my hobby math
subject, geometry is (with the as few polynoms as possible :-)


Thorsten

Post a reply to this message