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/."

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 [slashdot.org] 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:Red rectangle?

[scubaken]

cpo is one of the best i have seen. Its a scene from the movie "core". It depicts the center of the earth thru the window of a research vessle that has been dispatched to the center of the earth. ILM or Lucas Arts should hire this guy for a movie or something, IMO

fooey

[Sparr0]

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.

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

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.

Re:fooey

[mkmoose]

If this interests you check out the alias Maya Personal Learning edition(free)contest. http://www.alias.com/eng/community/contest/ You develope and animation and scene for a preprovided wireframe. 53 days left to submit. I may or may not make a submition but it is fun to play with.

Size coding

[termos]

Size coding can be a lot of fun, you should check by pouet [pouet.net] (seem to be down right now) for some 256b, 128b and even 16b productions, 256b.com [256b.com] has some more.

Very impressive stuff. :)

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.

Re:Where's the code?

[Sparr0]

RTFA. The site says the code will be released after the voting is completed.

My favourites

[Thornae]

Here's a few that impressed me:
"The Agate Face" [swin.edu.au]. 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) [swin.edu.au]
"City" [swin.edu.au]
"Simple" [swin.edu.au]
(No title) [swin.edu.au]

Also, the judging method is interesting:

• Each voter will choose their six favourite images based upon artistic merit. A first choice will get 6 points, the second will get 5 points, and so on.
• The gold place winner will be determined by dividing the total number of points awarded by the byte count.
• The silver place winner will be the entry with the highest number of points.
• The bronze place will go to the entry with the highest number of points divided by the square of the bytes used, this rewards the lower byte counts while still requiring an interesting image.

Perhaps this entry [swin.edu.au] is counting on getting a couple of votes and winning the bronze...

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".

Re:My favourites

[cybermace5]

The Agate Face apparently uses the isosurface command that not many people get into. It's very powerful. I assume it's called Agate Face because they used the agate map as the function input to the isosurface, maybe with the turbulence turned up a bit.

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.

Re:Interesting

[Anonymous Coward]

Apples and oranges, my friend. This contest features entries from some of the best POV-Ray artists in the world, vs. some random students in your school.

Speaking as an engineer who dropped out of art school many years ago, for any decent art program, it's a *lot* easier to get in than it is to graduate. Sure, the attrition rates were high in EE, but they were nothing to the tiny number of students the department allowed to stay.

Re:Interesting

[dustman]

Ironically, I just came from my school's gallery, and was musing on how painfully uncreative and uninspired the works there are.

I'm a programmer, not an artist, but it might be the case that stuff in your school's gallery was assigned work, that allowed little room for being creative or inspired, and is there because it's a good example of a technique.

"Paint a still life involving fruit and a table cloth"... There is not really much room for being creative or original there, how many thousands of painti

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 [reset.jp]; 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...

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.

Re:Nobody packages POVRay

[Tri]

It's actually in the non-free archive, which means that it's not part of Debian. This is not necessarily a bad thing, but it means that it won't be auto-built on other architectures than the one the maintainer uploaded it in, unless a Debian Developer takes the effort to do it.

Re:Nobody packages POVRay

[Kvorg]

That is a very interesting point! I missed out completely that non-free addons are not built on all architectures.

Of course, this and the whole MegaPOV thing is mostly due to the licensing of POVRay, and can't be helped easily.

On the other hand, it is quite difficult for me to make my mind up on the free/non-free issues for distributions such as Debian. I understand the logic, by being fully dependant on Pine (my fingers know the bindings) and in love with things such as POV, I give some credit to users w

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.

POVRay license

[0x0d0a]

It's true that the POVRay license is rather unusual, and does prohibit commercial distribution. (According to their legal page [povray.org], 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.

Re:Nobody packages POVRay

[kent_eh]

It is, however, available as a FreeBSD [freebsd.org]
port. Also several add-ons.

Ahh, POV

[standard method]

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