 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Any interest in another short code contest?
The last one was over 2 years ago
http://local.wasp.uwa.edu.au/~pbourke/rendering/scc3/
I wondered about adding a new twist to make it harder .... under 256 bytes
and use only spheres. I'm up to organising it if there is sufficient
interest.
-------------------------------------
P a u l B o u r k e
http://local.wasp.uwa.edu.au/~pbourke/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Bourke wrote:
> Any interest in another short code contest?
That would be great i think.
> The last one was over 2 years ago
> http://local.wasp.uwa.edu.au/~pbourke/rendering/scc3/
> I wondered about adding a new twist to make it harder .... under 256 bytes
> and use only spheres. I'm up to organising it if there is sufficient
> interest.
You probably mean 'spheres are the only *shapes* that might be used' -
otherwise without colors, textures, light sources etc. the results would
be pretty boring...
It could be that with such a restriction the results will be less
interesting for non-technical people. What might be better is to have a
certain 'base scene' every submission is appended to when being rendered
and at the same time reducing the number of characters allowed. There
could for example be a light source, camera, background and radiosity
block predefined.
Another possible variant would be to disallow certain characters in the
code (like for example the only digits allowed being '0' and '1'). ;-)
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 20 Aug. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Bourke <pdb### [at] swin eduau> wrote:
> Any interest in another short code contest?
I would certainly try to participate.
> I wondered about adding a new twist to make it harder .... under 256 bytes
> and use only spheres. I'm up to organising it if there is sufficient
> interest.
I agree with Christoph that, while this would increase the challenge,
it will most probably cause the results to be less spectacular because
the images will be much simpler than in a "freeform" contest. You just
have to look at the scc3 results to see what I mean with "spectacular".
(And it was indeed something which was awed even at slashdot.)
Perhaps try with another "freeform" contest (ie. limited only to a
number of bytes, like the scc3), and if there's enough participation,
then we could think as a group if some other "challenging" ideas could
be used for a next contest? Just an idea.
Some things should be learned from mistakes in scc3, though. The most
prominent one is, naturally, that it doesn't make sense that the same
image can get both first and third positions. Winning positions must
be exclusive (IOW even if an entry would classify for more than one
position, only the best one is given to it; the second-best image for
the other position is selected for that other position).
Also I think that, while this *is* a "short code" contest, perhaps a
bit ironically, less weight should be put into the actual length of the
code (as long as it's inside the required limit). Putting too much weight
in it only causes extremely short-code images to get illogically good places
which they don't seem to deserve on basis of their visual content. Or
if I express the same thing bluntly: Ugly images will get good positions
only because they are extremely short.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Bourke wrote:
> Any interest in another short code contest?
Hey, I would do my best to participate in this one... it sounds like
fun! Now, if I get to have internet access for that long.... that's
another issue /:-o
> The last one was over 2 years ago
> http://local.wasp.uwa.edu.au/~pbourke/rendering/scc3/
> I wondered about adding a new twist to make it harder .... under 256 bytes
> and use only spheres. I'm up to organising it if there is sufficient
> interest.
The spheres limitation might be too extreme. I always thought part of
the excitement around the short code contest was that you could make
complex scenes in POV without using a large amount of HD space....
~Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Bourke <web.45167b93e2218d9685a114a40@news.povray.org> Sunday 24 of
September 2006 14:36
> Any interest in another short code contest?
> The last one was over 2 years ago
> http://local.wasp.uwa.edu.au/~pbourke/rendering/scc3/
> I wondered about adding a new twist to make it harder .... under 256 bytes
> and use only spheres. I'm up to organising it if there is sufficient
> interest.
> http://local.wasp.uwa.edu.au/~pbourke/
I liked the previous SCC :) even if I didnt won any place :/
I have other interesting (perhaps idea) - only 127 bytes, BUT allow a list
of shortucts.
like
#macro s sphere #end
#macro b box #end
#macro p pigment #end
and so on (1 letter for most common, 2 letter for less common tokens)
and the list file is downloadable from SCC site and do not count
the
#include "scc_tokens.inc" do not count, so the file itself will be for
example
128 + 26 bytes
and it will be like
D{b{1,-1}s{0,1}s{x,1}}
meaning
difference { box { 1,-1 } sphere { 0,1 } sphere { x,1} }
--
Cytat tygodnia:
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I wondered about adding a new twist to make it harder .... under 256 bytes
> > and use only spheres. I'm up to organising it if there is sufficient interest.
> I agree with Christoph that, while this would increase the challenge,
> it will most probably cause the results to be less spectacular because
> the images will be much simpler than in a "freeform" contest.
On second thought, yes I agree. Enough that it is a short code contest, no
need to restrict the content.
> Also I think that, while this *is* a "short code" contest, perhaps a
> bit ironically, less weight should be put into the actual length of the
> code (as long as it's inside the required limit). Putting too much weight
> in it only causes extremely short-code images to get illogically good places
> which they don't seem to deserve on basis of their visual content.
Again agree, this time judged purely on merit and no judging weight put on
the length.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I have other interesting (perhaps idea) - only 127 bytes, BUT allow a list of
shortucts.
> #macro s sphere #end
> #macro b box #end
> #macro p pigment #end
I don't think so, the "elegance" of this contest is that everything is
contained in one file .... along those lines I planned to disallow
"#include".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I don't think so, the "elegance" of this contest is that everything is
> contained in one file .... along those lines I planned to disallow
> "#include".
#version 3.6
#include
"my_incredibly_large_mesh_file_that_takes_up_gigabytes_of_space.inc"
#include
"my_poser_5_figures_geom_file_that_takes_up_megaabytes_of_space.inc"
#include
"my_very_large_scene_file_that_takes_up_only_kilobytes_of_space.pov"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Bourke <web.4517308255b9135e5a039020@news.povray.org> Monday 25 of
September 2006 03:27
> I don't think so, the "elegance" of this contest is that everything is
> contained in one file .... along those lines I planned to disallow
> "#include".
This would be the only allowed file.
Povray syntax - it is nice to read, but time and space waste to type in,
especially in short code contest.
With my one include as above, you would be rather limited to the number of
primitives/directives you can use, not to the length of their names.
--
Cytat tygodnia:
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Raf256 <spa### [at] raf256invalid> wrote:
> > I don't think so, the "elegance" of this contest is that everything is
> > contained in one file .... along those lines I planned to disallow
> > "#include".
> This would be the only allowed file.
It still feels like cheating. "Oh, he is allowed to use a rather
large include file. This is not a short-code-contest."
If the include file is used, its size matters. It's not a "short-code
contest" if it uses a large amount of code.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
