Notes on Lisp raytracer.

just another diary

Tuesday, April 5, 2011

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.

Tuesday, January 25, 2011

Parse-line

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

Here is the result.

Wednesday, January 19, 2011

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.

Sunday, December 5, 2010

Timeout

This blog is not abandoned (as you might have thought).
I'm just a little bit overwhelmed with the amount of the information I got.
Currently I read "On Lisp" by P. Graham and it takes a lot of time.
As soon as I finish it, I will continue with RT.

Tuesday, December 29, 2009

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")

Thursday, December 17, 2009

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.

Thursday, May 14, 2009

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.

Saturday, November 22, 2008

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.

Thursday, October 2, 2008

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.

My Blog List

  • Emacs or Ubuntu sucks. - I have a part in my dot-file that positions the Emacs window on the screen. It works on all OSes: Windows, OSX and linuxes. I use only Ubuntu for now and g...
    3 years ago
  • Under impression. - I still cannot believe that this was coded. At some point I convinced myself that this should be some kind of music video. But then... They have said that ...
    3 years ago
Powered by Blogger.