Brett A. Letner precises his wishes concerning the inverse function.
Somebody objected :
> >> that is not possible in the general case.
> >> Not to forget that even if it was, not all functions has inverses.
I understood (apparently correctly) that Brett *knows* the inverse of
functions he is interested in.
The problem is that in Haskell it is not possible to distinguish
between functions, they do not belong to the Eq class, and any attempt,
say
discr fun = case fun of
sin -> "allons"
cos -> "enfants"
exp -> "de la"
sqrt-> "patrie"
to pinpoint a function object will fail. (Hugs will respond "allons" to
everything, "sin" here behaves as a non-discriminated variable).
But you can always envelop a function in a record and add a *constant*
label, say (Inv "sin" arcsin), and use such a structure instead of your
function.
But, frankly, I still don't understand <<cui bono>>. Brett wants to
write a ray tracer in Haskell, and states that
> it seems like this problem is perfectly suited for
> a functional programming language (limited IO, obvious recursive
> algorithm).
Hmmm. The IO is not so limited in a *real* case. Concretely, you
generate pixel by pixel, and you have to operate upon an *updateable*
frame buffer. Recursion is mainly needed for the secondary rays, for
the reflection & refraction, but the bulk of the complexity is
elsewhere. It is the calculus of intersections with *all* the objects
of the scene (after the BSP optimisations, bounding boxes, etc.)
> The way I was looking at attacking this problem was by representing each
> primitive object as some easy to work with base object, followed by any
> necessary transformations.
> ... example omitted ...
No, I don't think that representing an object as the "base" entity
plus its transformation is a good idea for the ray tracing. It is
*good* for the *process of modelling*, as it permits to keep a compact
representation of all the undoable modifications, but when you launch
the rendering procedure, the objects should be as static as possible.
In fact, in the most general case they should be represented as
implicit equations F(x)=0. Then, injecting a parametric equation of
the ray: x=x0 + ut where u is the direction vector, into it gives you
a scalar equation F(t)=0, which is simple cases (planes, quadrics)
admits a direct analytic solution, otherwise some numerical procedure
must be applied.
There is another sub-domain of image synthesis through RT which seems
an excellent training field for functional programming: the construction
of dynamical shaders, procedures added by the user, which compute the
textures, volumetric effects, perform local deformations (bump or
displacement mappings) etc. This is something which is badly missing
from
most ray tracers, and the Renderman-compatible ones (BMRT, etc.) use
a specific "shader language" which is worse than C!
============
Sergey Mechveliani proposes:
> For the ray tracer programming, i would rather suggest to represent
> a surface as polyhedron, its sides - as bases of vectors, vectors -
> as the number lists, transformations on rays - as matrices.
> Then - apply standard techniques with linear algebra of matrices.
> And polyhedron matters, convex bodies and such, it is still a mess.
> The whole subject is hardly a matter of programming language.
> This is mathematics, geometry. Any programming tool will be good -
> if only it provides a good piece of library for such geometry.
> I am not sure, but probably, Maple, Axiom, other computer algebra
> systems have something for this.
Yes, and no. First, no mess at all, the mathematics is quite venerable,
with a good deal of optimizations, complexity analysis, etc. Not only
standard matrix algebra is used, but also quaternions and differential
forms.
Then, for the ray tracing, polyhedra have *no sex appeal at all*!
At least, the polyhedra given by their B-rep: vertices, edges, polygons
as lists of edges, etc. This is an adequate representation for the
scan-line algorithms (or radiosity), but for RT a polygon as a list of
vertices or edges is useless, in order to find its intersection with
a ray, the basis is the *implicit equation of its plane*! It should
be reconstructed from the B-rep before the rendering.
Of course, this can be done in any language, and functional ones are
better than many others, but please, don't reduce all this to geometry.
This is a practical programming problem, efficiency of data structures,
etc. The visualisation tools embedded in symbolic manipulation
packages as Maple or Axiom are average, much worse than they could
be. In some cases - e.g. the rendering of implicit surfaces by
polygonization in Maple is buggy and very inefficient...
The treatment of textures, illumination, etc. is much better in
Matlab or IDL, and - which should be noted here: a good part of
its visualisation code is quite functional in *STYLE*, but relies
upon very efficient array processing procedures.
Give me that, and I will make you a reasonable ray tracer in Haskell.
For the moment I plan (?) to do something of that kind in Clean.
Ray tracers show their power outside the polygonized world, they
are good for rendering blobs and other fuzzy objects, to cast
shadows in an easy way (not necessarily super efficiently, but easy
to program, in fact there is nothing to do...), to play with a
textured light sources etc. The underlying models might be very
nicely represented functionally, but the RT engine seems unfortunately
out of this game.
Jerzy Karczmarczuk
Caen, France
