POVRay Short Code Contest, Round 3

An anonymous reader submits "The aim of the POVRay Short Code Contest SCC3 is to create an artistic work using POVRay (a free raytracing program) using only a limited number of bytes. The last round had an upper limit of 500 bytes and this round increased the challenge by reducing the maximum number of bytes to 256 (about 2 average length English sentences). This round saw some exceptional entries, an example of extreme image compression since these images can be created at any arbitrary resolution! The competition is now closed to entries and voting, which is open to the public, has started. The 51 entries can be viewed here. POVRay can be downloaded free from povray.org/."

Comments

Red rectangle?

[Anonymous Coward]

I'm all for minimalist but whats with the cpo entry? It's just a red rectangle! That must have been REALLY hard to do in 256 bytes...

Re:Red rectangle?

[Cecil]

The author of cpo is aiming very squarely (excuse the pun) at third place. Check out this post for more information. Given the undoubtedly tiny number of bytes, if he even gets a few votes I think he's almost guaranteed a third place finish.

Kind of an interesting approach at subverting the calculations for third place, but a bit against the spirit of things, so it won't get my vote.

Re:fooey

[yotaku]

One think I used to enjoy taking part in is TopCoder. They hold small online coding competitions that only take about an hour and a half to take part in - and are quite a lot of fun. Plus they are held about once a week. So you dont have to worry about missing one because there will always be another one just around the corner.

http://www.topcoder.com

Where's the code?

[tweder]

If this is a code contest, should we see not only the output, but what it took to get there?

JPEGs are nice and all - don't get me wrong. But I'd much prefer to see the code as well.

Interesting

[Mark_MF-WN]

Some of those images are pretty generic stuff, but some are quite interesting aesthetically. Ironically, I just came from my school's gallery, and was musing on how painfully uncreative and uninspired the works there are. Yet a silly little contest over the internet can produce some very creative pieces of work. It sure makes ya think.

Incidentally, if you have any plans of studying art at a University, rethink those plans immediately. Art college may be expensive, but I've seen the quality of the work from the local art college and it absolutely embarasses the theory-trained hacks who populate my University's art school.

Indeed, "Simple" was cool

[PateraSilk]

The sphere was so elegant, especially the way the light bled around the form. Very nice.

All in all, I'd say that this was a fascinating display of "less is more".

Slashdot Contest Proposal

[0x0d0a]

I think that Slashcode could benefit from a timeline model for stories, much like how some professional news sites work.

It would be interesting to have an article that opens a timeline "The 2004 POVRay Small Code Contest", and one that closes it. The same would be true for "The SCO Lawsuit". Currently we have categories, but that doesn't exactly do the same thing.

Plus, a lot of folks say "I'm not interested in Foo, and wish I didn't see stories about it", but if there were timelines, as soon as they see a timeline that they aren't interested in, they could omit it from their Slashdot story listing.

Slashdot editors currently sometimes build ad-hoc timelines by reverse-linking stories to older stories in the same genre, but it's fairly rare that they do this.

Nobody packages POVRay

[0x0d0a]

I've always been surprised that POVRay is not packaged by any of the major Red Hat packagers -- dag, freshrpms, or fedora. I would think that a lot of people would use POVRay. [shrug] Well, maybe not.

Re:Nobody packages POVRay

[Kvorg]

Debian does, of course, but if you need RPM, SUSE does it (even 64-bit). Third-party providers (mostly inidividals) ship it for Fedora, such as Matsuura Takanori; but you probably know that :) - it might still help some old hand wanting to toy with the examples once the voting is over...
I wish some of the extensions (MegaPovRay, anyone) would be as quick to install on a large number of machines...

Re:Nobody packages POVRay

[John Courtland]

I bought a book back in the day (DOS 6.22 was still very big but Win95 had just come out), on C++ Games Programming by Al Stevens and Stan Trujillo (from Dr Dobbs). It came with a CD containing various game creation tools. It was supposed to contain POVRay as a rendering tool, but according to the text, they had to drop POVRay from the CD because of a distribution deal with a different publishing house, I believe. Maybe the same problem here? Or maybe even POVRay doesn't want problems like that any longer so they don't allow distribution except through their methods? I haven't seen the website in a while, and I usually have little concern for the legal mumbo jumbo that adorns licensing agreements, so I may be wrong there.

The tribulations of the RPM political scene today

[0x0d0a]

The problem with using SUSE RPMs is that standardization in spec file format is actually rather poor. The chance of being able to use a Mandrake RPM or SuSE RPM on a Red Hat system flawlessly is minimal, but one would hope that SRPMS would build properly. Nope. Each distro provider has a different set of spec file macros included, different requirements about builds (for example, Red Hat is pretty strict about RPMs also being capable of being built as non-root users, which a number of others distros do not require). Furthermore, the errors are *not* particularly simple to troubleshoot for an end user, because there's no real way for RPM to intuit what a macro should have meant...an unknown macro is simply executed as a shell command. This is very much a flaw in the RPM spec file format -- it's mostly just a shell script that gets rammed through a bit of preprocessing, instead of a proper format. Spec files also have duplication of information (the files installed and the list of files packaged). IMHO, basic packaging is not a very difficult task from a technical standpoint, at least if one simply wants to formalize the list of files in a package. However, it is *extremely* difficult to make really good spec files that conform to all the requirements of a given distro vendor and don't break when a user builds an RPM as a user, or when a user has bz-compressed man pages instead of gz-compressed (or uncompressed) man pages, or something along those lines.

I'm similarly often exasperated with autoconf's oddities and syntax -- it's incredibly hackish, a mass of macros.

I've downloaded RPMs of povray before...I just wish that the major folks, the ones that really know RPM and spec and the distro requirements and issues involved inside out included povray.

As for MegaPovRay compatibility -- I agree. I do have to say that Povray backwards compatibility isn't the greatest. In the software world, it would be a sign of terrible design to say "Well, you need to use version .3 of the library...version .4 causes our software to work differently". However, there are many POV source files out there that don't work past a given version, or require a particular and unique set of extensions. I think that if POV was produced today, instead of having its own language, it would probably be a set of bindings to something like python or java.