Working on KD-tree.

Trying to implement KD-tree for the ray tracer, I solve appearing problems with both environment and the language itself.
Anyway, the result can be found any moment on the github.

Currently I am working on KD-tree, on the build-tree function, to be specific. The most difficult part of it seems to be a SAH function (surface area heuristics).

And the next difficult part would be a traverse-kd-tree function, which is implemented, but I am looking for good testing techniques for it: a 3D geometrical data is difficult to visualize either in console or on screen.

Parse-line

Spent a lot of time trying to simplify and clarify the function parse-line.

Here is the result.

KD-tree

I spent a lot of time.. er.. well, I wasted a lot of time fighting with Emacs, SBCL, SLIME, quicklisp, lispbuilder-sdl, MacOSX port of lispbuilder-sdl-gfx and other stuff.
Now I am a little bit closer to my goal: skills in Lisp development.

Anyway, I forced my code to work at least on Windows.
Currently it builds a KD-tree of given OBJ-file and displays it in animated manner.

The code is available here.

Don't hesitate to contact me if you wish to run it.
I guess you would need my help.

OBJ file format.

For this raytracer I chose to import the OBJ file format as the easiest one to parse.
So here is the first draft implementation of the importing of vertex positions.
This simple code is ready to use, the form is: (take-vertexes "test-file.obj")

Random rays.

Trying to generate random rays, I have got a problem.
Basically I had few ways to get a 'random' vector or in other words a random point on the surface of the unit sphere.

Renderman.

It seems that if I want to follow industry standards, I have not too much to choose from. It is either Renderman or Mental, or Blender, or something like Cg or alike. Yes, I know that they are "of different type", but my problem is to choose something distant just to set the direction. I have no preferences, and so after talk with one guy, the Renderman was chosen. Yet I have no idea about reyes and other renderman-specific things, but I will find it out.

Direction.

I thought a bit about this task and more and more I like the Haskell with its laconism. And more and more I see that LISP is pretty weak here comparing to the Haskell. But on the other hand, as LISP has weakness here, it has a strength somewhere else. And I believe, it is macros. Just because the LISP has nothing special else.

So now my idea is to pay as much attention to macros as possible. I don't want to put them just everywhere, but simply to make the language more laconic.

And one more thing, but not the least. I decided to implement the support of some already available shader language just to be able to use the code already written for this lamguage. I am still deciding which language to chose.

Next, please!

Ok, I canceled this latest change. But the library is implemented (well, taken...) and can be used any time.
The main reason for cancellation is that I get and absorb the information faster than I implement "the best" idea I have for the moment. And that lazy computation can tie me too much. Anyway, it isn't Haskell. Alas.
So, now the best idea is this:
I design the language like LEGO, i.e. the language that permits to work with blocks of calculations. I imagine it like Houdini net editor or something like that with textual description. Maybe it will be XML.
I haven't decided yet.

Streams.

Impressed by lectures of Gerald Jay Sussmann and Harold Abelson, I decided to put the streams into the rendering engine to simplify it and to add lazy calculations. I'm too "imperative" and it takes some time and pain to move to functional style.

One may say "First implement it and then play", but I desagree. Features are just a bunch of code which will prevent me from doing any changes. So now is the most correct time.

Self-testing.

So there is new feature in the renderer available.

It is a testing framework from the "Practical Common Lisp" book. The book is awesome and I recommend it for reading for everyone who did not read it yet.

Anyway, I took the "framework" as it is without changes: it suits well as it is.

So, not too much, but the code is revisited a little bit and, anyway, it is a progress.

One small step is better than nothing...

By the way, on the picture one can see the new "checker" shader: it shows V direction with white and U direction with solid color, putting the round mark at the first vertex in the list.