Hard At Work, Or Hardly Working?

Trish's dad and I are re-doing the front yard. So far, we've stripped off the old porch, and are reinforcing the supports, while we wait for the new decking to arrive. This involved much sledge-hammering, pry-barring, and entirely too much nail-removal.



Here I am, working hard!

Easy Procedural Graphics: Python and POV-Ray

I've been working on some ideas for procedural graphics recently. For the non-programmers out there, that means graphics that are designed (not just drawn) by computer programs, not by humans.

I've found a very productive (and free) way to experiment, using Python to write the code, and POV-Ray to draw the results. The one drawback is that POV-Ray is not a real-time renderer. I.e. it takes a few seconds to draw the scene, so you can't move around in it interactively. That aside, using just a few scripts you get an efficient workflow with fast turnaround.

I'm using Python more and more. At this point, it's my default language, because I'm so productive in it, versus C++. I've got a custom vector math module and a simple renderer (both co-written with blu) that are written in C++, but wrapped for Python, using SWIG. At some point, I'll switch over to the real-time renderer, but at this point using POV-Ray lets me concentrate on just the new procedural research.

The one Lisp feature I miss in Python is full-powered macros. Sometimes you just need to generate code. C++'s macros and template-metaprogramming are pathetic and horribly complicated by comparison. That said, some really smart programmers, like Andrei Alexandrescu, have gone to heroic lengths to show the possibilities of template metaprogramming. Unfortunately, you're still limited by the fact that this isn't C++'s strong suit.

In the end, macro programming and template meta-programming are just special cases of metaprogramming. Using a language that has strong support for text-manipulation (like Python, or Perl), it's not too difficult to just generate program text using the language. Unfortunately, you don't have the clean integration that Lisp's use of S-expressions (i.e. transparent access to the syntax tree) provides.

POV-Ray defines the scene to be drawn using a simple textual scripting language. I wrote a bunch of code to generate POV-Ray code for scene objects. Apparently, there's already a module out there to generate POV-Ray code using Python code, written by Simon Burton. I like the way it's designed; it makes great use of Python's keyword arguments. The only drawback is that it generates the output file right away. I'd prefer to have a graph representing the scene, then have the option to output to a string, and then to a file. Kind of retained-mode versus immediate mode.

At any rate, that module is lower-level than what I'm doing, but it's a neat substrate to layer on top of. I'll probably move my code on top of a modified version of this layer, and upload my changes to the base layer.

For some amazing graphics demos using procedural graphics, check out this stuff by the farbrausch demo-group:

fr-041: debris
fr-034 / hjb-104: time index,
and of course, fr-025: the.popular.demo

These demos were created with various version of their interactive procedural-generation tool, werkzeug.

Of course, a lot of this stuff was done 15 years ago, in Lisp, by Karl Sims.

Finally, for some impressive games using procedural techniques, check out ABA Games by Kenta Cho. He even provides source-code. It's written in D, but that'll have to wait for another post.