TODO

Near term

Vertex buffer objects

I’d like to model this on immediate mode rendering. Non-vertex information should be stateful.

(create-buffer :triangles [:color :normal]
  (color 1 0 0) 
  (normal 0 0 1)
  (vertex 0 0 0) (vertex 1 1 0) (vertex 1 0 0))

This will create a vertex buffer with three per-vertex colors (all red) and three per-vertex normals (all z-axis facing). Similarly, an existing vertex buffer can be overwritten at a particular position (open question: do our indices represent vertices or primitives?) with a (write-to-buffer ...) macro. An (append-to-buffer ...) macro would also be useful.

Texture dictionaries

If we want to use textures in a vertex buffer, all of our texture coordinates need to be w.r.t. the same texture. To accomplish this, we can take a bunch of smaller textures, and combine them together. This will take the form of passing a sequence of textures to a (combine-textures ...) function, which will return an altered sequence of the same textures. This dovetails nicely with the (with-texture ...) macro, which can just do a texture-space transformation. The transformations will have to be in the intermediate transformation layer while defining a vertex buffer.

Windowlets

Currently, there’s only one set of callbacks. If we instead define a hierarchy of callbacks, where mouse inputs are propagated upwards towards the root, and rendering downward towards the leaves, this gives us some interesting capabilities.

• We can create 2-D widgets, which can themselves contain other widgets, and so on.
  • This is a necessary precondition for rich 2-D interfaces. It won’t be Swing, or Flash, but it will be a pure Clojure implementation with the ability to leverage OpenGL. That should allow for some interesting things.
• Common interface elements can be factored out, and composed.
  • An FPS camera can be viewed as a combination of several different controls: mouse-motion rotates the world transform and requires no information about the world, WASD translates the world transform and requires collision information. Each of these are composable pieces, which can be written once and reused.

Longer term

OpenCL

This should be pretty easy, I think. GLSL is currently represented as a thin semantic layer over a sexpr → C translation. Adding in OpenCL won’t disturb existing functionality, and if I’ve chosen the right level of abstraction, will fall into place.

Constructive solid geometry

This would just be cool. Maybe the GPU can be leveraged?