Re: [grt-talk]Development Thoughts

[Jason Dagit]

Nikodemus Siivola wrote (on Sun, 30 Mar 2003 at 00:55 +0200):

 > Top of todo-list:
 > 
 >  Engine: 
 >  - 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
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...

 >  - 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?

 >  - 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.

 >  API: 
 >  - clean separation from the engine so that the slow-but-nice
 >  API can be experimented with without interfering with the engine 
 
 >  - redesign of API: 
 >  * Stuff the scene into a variable 

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...

 >  * Patterns need a particularly well thought out API so that simple
 >  things are quick and short to write, but complex things remain
 >  possible. This probably means a ton fo convenience functions.

Yes.

 >  Frills: 
 >  - better rendering window (cl-sdl, 

This would actually be pretty easy.  The hard part would just be
finding an easy way that the end user could use their preference of
CLX and cl-sdl.


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 think the main thing for me at this point is that I need either 1)
to be told what to implement in a fairly narrow sense or 2) I need to
be handed reading material about what we need.

After I get a feel for raytracer design and a feel for GRT those 2
above are going to be about the only way I can contribute
meaningfully.  

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....

Jason