The fourth POV-Ray Short Code contest was held half a year ago. Since it seems that I wasn't following the correct information channels, I hadn't even heard about this competition until a couple of days ago when I was looking for the entries of the previous round. It's really a pity that there was this kind of information gap, since it would have been interesting to participate.
Just like in the third round (which took place in 2004), the length of the code (scene description in plain text) was restricted to 256 bytes, but this time it was no longer allowed to use external includes (e.g. standard texture and color definitions). At the first glance, this seems to have resulted in more use of "coder colors" and "coder textures", although many of the entries are still pretty nice-looking.
What I personally like in POV-Ray is that it has always emphasized procedurality and "write-it-yourself" kind of approach, which makes it a fun toy to experiment with. However, it's not always as clever as you might expect from a program which people have already been carefully optimizing for two decades.
For example, I've been having this idea of an "infinitely detailed" scene that uses a lot of inter-object references to keep the memory usage down. Something like this, perhaps:
Now, we should have a very detailed forest planet that compresses very well into a short description and only hogs a tolerable amount of memory during rendering. In theory, raytracing should render this kind of ultra-detailed recursive stuff extremely well, at least compared to traditional polygonal engines.
But how does POV-Ray behave? It breaks the whole nicely structured scene into the smallest possible pieces: so, instead of just allocating memory for those 2 or 3 prototype models we defined in the scene description, POV-Ray allocates memory separately for each of those hundred billion leaves. Perhaps this is supposed to add to the rendering speed, but it definitely doesn't help us to keep the memory usage down.
It's quite common that when I think I have a groundbreaking idea and try to prototypize it with an existing tool, it soon becomes apparent that the tool is insufficient and I should've written my own program on the first place. Perhaps some day I'll write a tracer that implements all the unusual ideas I've been having in mind, but the time isn't just yet.