Re: [grt-talk]Development Thoughts

[Nikodemus Siivola]

On Sat, 29 Mar 2003, Jason Dagit wrote:

>  >  - affine transformations
>
> How much more needs to be done to get this?  I mean, from the looks of
> it you have the code in there for 4x4 matrix transformations.  From

Yeah. That was the thing I was last working on before the latest hiatus.
Unfortunately something wnet wrong, but my life got too busy before I could
figure out what. Might be that the way I applied the transformations was
jsut screwed, or it may be that the matrix code is broken.

> what I read on the web, affine transformations can be represented as
> linear transformations.  If you have some specific application in mind
> let me know...

Applications besides translations, rotations & co? The design is/was to be
able to apply arbitary transformations to objects, which get combined into
a single transformation matrix. Then whenever a ray is being intersected
with the object the inverse transformation is applied to the ray.

>  >  - CSG
>
> Hmm...I know what that stands for, but I have no clue how to implement
> any of it.  Do you have resources you recommend?

I'll try to include something in the link-list.

>  >  - map-based patterns
>  >  - patterned normals
>  >  - aa bounding boxes & octree
>
> Same as above.  Raytracing is new to me :) But, I am most of the way
> done with a bachelors in math, so if there are mathematically
> technical articles I should be able to handle them.

Ditto for resources, but as for the map-based patterns -- they are pretty
simple to explain, and not necessary standard terminology. First have a
look at the pattern code.

By map based patterns I mean using a mapping function[1] and a pattern
fucntion to generate a function that takes a point in space and first
applies the pattern function to it, then maps the resulting value with the
mapping function.

[1] These mapping functions would be generated from a combination of
samples in range 0-1, related values, and a blending function.

This way patterns could be easily applied to colors, other patterns,
vectors, floats, etc.

> I'm not sure exactly what you mean, but I think the current system may
> be a bit better and does it already to some extent.  Or precisely what
> I mean is that the current way to make a scene makes a lot of sense.
> You define a function that tells GRT how to create a scene.  And in
> lisp functions are data types so in some sense a scene can be stuffed
> into a variable already.  But perhaps I'm just missing your point...

I am referring to having to constantly call SCENE-ADD, and having to keep a
reference to the scene. For simple scenes this is not a big deal, but for
complex ones I fear it may bet quite tedious.

Instead I think there should be a global variable holding the default
scene, and maybe a single function/macro with a _short_ and convenient name
that adds a single object to the default scene -- for example SCENE.

Now:

  (let* ((scn (make-scene :background-color (rgb 0.6 0.6 1.0))))

    (scene-add scn (light :location (grt-vector 0.0 5.0 -15.0)))

    (scene-add scn (plane +y+ (grt-vector 0.0 0.01 0.0)
                          :pigment (make-pigment
                                    :pattern (make-checker-pattern 0.0 1.0)
                                    :list (list +white+ +black+))
                          :reflection (make-solid-pattern 0.1)
                          :ambient 0.4
                          :diffuse 0.6))

Possibly in Future:

 (setf (scene-background *scene*) (rgb 0.6 0.6 1.0))

 (scene (light :location (vector 0 5 -15))

 (scene (plane +y+ (vector 0 0 0)
          :pigment (checker +black+ +white+)
          :reflection 0.1
          :ambient 0.4
          :diffuse 0.6))

Not a big deal, but bloody convenient. Also, the scene building API should
/ could be quite smart, assuming intelligent things. For example, guessing
default colors for objects based on the current background color, and
default sizes and positions for various objects, and handling input of
various types intelligently: converting vectors to grt-vectors, floats to
solid patterns when necessary, etc.

> I think another set of frills we could consider in the future is a set
> of API for taking a collection of rendered scenes and playing it back
> as an animation.  I'm thinking the play back would be the easy part,
> the more complex part would be providing routines for animating
> objects.

I'm not quite certain what you mean:

When speaking about rendered scenes, do you mean images? If so, than there
are several such programs already.

Or are you referring to adding animation support to the API? If so, then I
definitely agree. At heart there needs to be a global consept of time, so
that you can write something like:

 (light :location (grt-vector (* 3.0 +time+) 0.0 0.0))

 (render :frames 50 :render-frames '(10 20) :time (0.0 1.0) ...

Good splines (and a great spline API) are a must as well: probably a
separate graphical spline-editor as wel.

> 1) to be told what to implement in a fairly narrow sense
> 2) I need to be handed reading material about what we need.

Fair enough. Another thing that I'd really appreciate is if you'd point out
the ugly spots in the code -- seriously, I knew Scheme before, but GRT is
the whole of my Common Lisp experience, so critique is needed.

As for no. 1, I'll try and rewrite the TODO in CVS so that others besides
myself can understand it. Then it's your pick. ;) I'll see what I can do
about number 2.

> I would like to mention that I suggest renaming vector-bind to
> grt-vector-bind since it operates on grt-vectors and not vectors as
> per CL.  That's the only bit of API I've messed with thus far....

I'm afraid you have a good point there. I just dislike long names myself,
but unless we start referring to grt-vectors as point there is little
point. Then again, maybe it could be rewritten as triplet-bind, so that the
same macro would be used for vector and colors...

 -- Nikodemus