Slashdot Mirror
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/."
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...
This is the kind of thing I hope to see posted on /. BEFORE the entry deadline. And preferably a sane time before, not 1 day like that PHP Blackjack thing. I would have very much enjoyed participating in this event.
Size coding can be a lot of fun, you should check by pouet (seem to be down right now) for some 256b, 128b and even 16b productions, 256b.com has some more.
:)
Very impressive stuff.
Note to self: get smarter troll to guard door.
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.
"The Agate Face". An incredible piece. Could be a photo of the cliffs near where I grew up. I'm looking forward to seeing the code for this one.
(No title)
"City"
"Simple"
(No title)
Also, the judging method is interesting:
Perhaps this entry is counting on getting a couple of votes and winning the bronze...
|>
Here be Dragons
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.
All in all, I'd say that this was a fascinating display of "less is more".
Danke tres mucho, tovarishch.
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.
May we never see th
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.
May we never see th
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.
.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.
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
May we never see th
It's true that the POVRay license is rather unusual, and does prohibit commercial distribution. (According to their legal page, the POVRay community has been apparently trying to move away from this to something more common...I hope the BSD or GPL license...and this will apparently be done with the v4 rewrite).
The thing is, while Fedora can be now, I suppose, considered "commercial", Dag and Freshrpms are decidedly not commercial.
Good thought...I suppose that could be the problem.
May we never see th
POV-Ray was really my first introduction to any sort of decent graphics program. Back in the mid 1990's I found a DOOM modification on a CD (it was a Barney mod, embarrassingly enough), and the sprites had been rendered in a pre-POV version of the program. I can't recall the name of the program off-hand, but it didn't exist anymore by the time I searched for it. However, I did find its eventual successor, the mighty POV-Ray. I remember clearly how obsessed with that program I was, and how excited I was when I was able to properly tear apart shapes.pov and render my first blue sphere.
Of course, these days, I haven't touched POV in months, and I still haven't done much of anything good with it, but I still love the program. I was half-heartedly involved in the Internet Move Project at one point, but I knew I was out of my league every time I read that mailing list.
But enough about that, back to the topic at hand. I've always been intrigued by things like this, doing the most with the least, though the person shooting for third place does seem to be souring the values of the competition a bit.
"I'll be a killer whale, when I grow up"
-Wintersleep