"Jellby" <jel### [at] M-yahoocom> wrote in message
news:40645f5e@news.povray.org...
> Among other things, Ross Litscher wrote:
>
> > i think the short code contest is the most flexible and challenging. i
> > would like to see several small increases in the size of the allowed
code.
> > maybe add 32 bytes to this next round, then another 32 bytes to the
> > following. it could be interesting to see how much more complex the
scenes
> > become after a few increases.
>
> It would be interesting to see it reach 1MB. Imagine: 1MB full of obscure
> compressed pov SDL...
>
> -- 

lol, eww. my eyes hurt just imagining the code.

Post a reply to this message

Pretty cool ideas, but let me offer some feedback on SCC3:

1) I think it would be helpful to have links to the SDL as an extension of
TXT rather than POV.   If it were to serve as an "evangelistic tract" for
the program, these snippets of code would have more universal viewability if
it's not going to have to cause a window browser to search hard drives for
nonexistent programs.   Even when browsing during coffee breaks in the
office on a PC on which I've installed povray,  I wasn't always eager to
execute povray each time I wanted to see an image...............

2)  Were all of the ratings of first place, second place, etc., based on the
points/bytes?   It wasn't clear on my two quick trips to the display site.

Other than that it is very well done.  I'm honored to have provided a seed
of idea for something that got mentioned at slashdot!    (:-D


Of the ideas below, I like the time to render one best.  But my brain is
scheming of a way to cook the formula so that the person who submits  a
black scene doesn't win based solely on a single 6th place vote!   I think
the limited geometry is a bit obtuse....




"Paul Bourke" <pdb### [at] swineduau> wrote in message
news:pdb_NOSPAM-78D05D.18372626032004@news.povray.org...
> Here are some ideas for a future competition (promted after the SCC3
> contest). http://astronomy.swin.edu.au/~pbourke/povray/scc3/final/
> Comments, suggestions, votes all welcome. These are in no particular
> order. By all means post suggestions to this group but also feel free
> to email me as well.
>
> Fast render
> -----------
> Idea by: Bernard
> Create an artistic image that doesn't take long to render.
> Voting much like SCC3 but the total vote weighted by the
> inverse of the render time.
> Concern: Getting the vote formula "just right".
>
> Short time
> ----------
> Idea by: Tek
> A theme is distributed and 30 minutes later (or some other short
> period) submissions are closed. This reminds me of lightning chess.
> Concern: Choosing a topic that minimises the chance of someone
> having a scene already on hand.
> Concern: Dealing with time zones.
>
> Limited geometry
> ----------------
> Idea by: Gary, Florian, Paul
> Create a scene with a limited range and/or number of geometric
> primitives. There are a number of variations possible here, one
> is "use less than N spheres" when N could be small or perhaps
> 1 million. Or, use less than N spheres, N planes, N boxes" where
> N might be between 2 and 10. Or, we assign a rating to each
> primitive and the scene has to be built where the sum of the ratings
> don't exceed some value.
>
> Tiling
> ------
> Idea by: Bernard
> Create a small tileable (in 2D) image constructed from 3D geometry
> Code would be uploaded and rendered at 256 pixels square, it would
> presented tiled as a background of a WWW page. As an example see
>    http://astronomy.swin.edu.au/~pbourke/tmp/tile/
> Voting perhaps the same as IRTC.
>
> 3D fractals
> -----------
> Idea by: Paul (me)
> Create a 3 dimensional fractal form, voting might be similar to the
> IRTC voting. In terms of creating attractive/interesting images this
> has great potential, perhaps not very imaginative (?).
> Concern: These often require many primitives and therefore lots of
> memory.
> Concern: There may be some debate on whether some forms are fractal or
> not.
>
> -- 
> Paul Bourke
> pdb_NOSPAMswin.edu.au

Post a reply to this message

> 1) I think it would be helpful to have links to the SDL as an extension of
> TXT rather than POV.   If it were to serve as an "evangelistic tract" for
> the program, these snippets of code would have more universal viewability if
> it's not going to have to cause a window browser to search hard drives for
> nonexistent programs.   Even when browsing during coffee breaks in the
> office on a PC on which I've installed povray,  I wasn't always eager to
> execute povray each time I wanted to see an image...............

Hmmm, is that widespread? 
I haven't used a MSWindows machine for many years now (don't even thing
I have access to one) so am a bit out of touch but isn't the correct
behavour
1. If there is a mime type set up use that.....therefore no delay.
2. If no mime type then prompt the user. If you don't like the ptompt
   set the mime type to your favurite text editor..the one you use for
   POV.

> 2)  Were all of the ratings of first place, second place, etc., based on the
> points/bytes?   It wasn't clear on my two quick trips to the display site.

See http://astronomy.swin.edu.au/~pbourke/povray/scc3/
First place is points/bytes
Second place is points
Third place is points/bytes^2

> Of the ideas below, I like the time to render one best. 

The problem I see with this is that it doesn't mean much to non
POVRay people. The short code contest could be appreciated by a 
wide computer literate community. Indeed people these days have a
higher expection when it comes to speed and so some nice image that
takes 1 minute might be considered cool by the POVRay community
but may give other people the impression that POVRay is a slow 
renderer.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

Paul Bourke <pdb### [at] swineduau> wrote:
> Hmmm, is that widespread? 

  It's a problem with IE. It does not care about the mime type of the
file but tries to "guess" what it is by the extension of the file name
and its contents (thus breaking all possible RFCs about this out here).

  (This is the reason why if a broken server sends eg. a .zip file with
the text/plain mime type IE will open it with winzip (or whatever) instead
of showing it as plain text as every other browser does. This has the
negative effect that people will think the other browsers are broken,
while it's the server which is broken and IE is breaking the standards
by ignoring the mime type. It discourages server maintainers to fix their
servers because they will not be aware of the true reason why their file
is not showing in the other browsers. This also has the effects that there
have been tons of IE exploits related to this: Sen a file with the image/jpeg
mime type, with a .jpg extension, but containing vbscript, and some older
IE version will execute the vbscript instead of showing a broken image
icon like every other browser does...)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

> It would be interesting to see it reach 1MB. Imagine: 1MB full of obscure 
> compressed pov SDL...
I guess some time earlier someone would try to develop some script to 
compress POV-syntax :) Could be an interesting job: While some stuff is 
trivial (e.g. spaces between vectors etc.) some are more advanced 
(shorten identifier and variable names) and some are really tough (real 
optimisation, like checking wether using an identifier or simply the 
numbers for a number occuring more than once is shorter).

But yes, it would look cool!

Florian

Post a reply to this message

> Fast render
> Concern: Getting the vote formula "just right".
True. Perhaps running a dummy contest first and try different formulas 
on the result and vote on which formula should be used.


> Short time
> Concern: Choosing a topic that minimises the chance of someone
> having a scene already on hand.
Additionally to a preclaimer like the IRTC one (image must be created 
for the contest), limiting the size of the file should be a good tool to 
keep the usage of already finished objects low.
> Concern: Dealing with time zones.
Don't think so. Either let the contest start two hours later each time 
(if it'll run several times) or choose a zone which covers most povers 
in a reasonable way (i.e. the competition falls for example somewhere 
from saturday morning 6am to saturday evening 12pm, which would cover 
already 18 hours).


> Limited geometry
> we assign a rating to each
> primitive and the scene has to be built where the sum of the ratings
> don't exceed some value.
Or an approach like the one with the inverse time: You may use as many 
objects as you like but you're points will be divided by the amount of 
objects (may be interesting to also count for example macros, textures, 
etc.).

> 3D fractals
> Concern: These often require many primitives and therefore lots of 
> memory.
Limit the memory: "Your scene is not allowed to use more than XX MB of 
memory. The value will be taken from the "peak memory" field of the 
render stats".
> Concern: There may be some debate on whether some forms are fractal or 
> not.
I would go for the fun and easy way here: It should look like a fractal. 
Letting only images of real fractals take part in the contest will IMHO

IMHO combining some of these would be cool:

"create an image which consists of a maximum of 10 spheres and 100 boxes 
which will render on <insert your machine here> in less than 1 hour. The 
scene may not contain more than 500 bytes and may not use any additional 
files. You got exactly 2 hours from 12:00 1st of April GMT."

Post a reply to this message

> I would go for the fun and easy way here: It should look like a fractal. 
> Letting only images of real fractals take part in the contest will IMHO

Now that happens if you push the "send button" by accident :(

here's the whole paragraph:
I would go for the fun and easy way here: It should look like a fractal.
Letting only images of real fractals take part in the contest will IMHO 
only limit the amount of contributors. Allowing a "it looks like a 
fractal, so it is one"-situation would not harm the competition (why 
should one enter a fractal round with sth. non "fractal"?) and would 
allow more artistic freedom.

Florian
*goes off and tries that send button one more time*

Post a reply to this message

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:406585c6$1@news.povray.org...

> > Short time
> > Concern: Choosing a topic that minimises the chance of someone
> > having a scene already on hand.


There's a random idea generator out there that will randomly juxtapose a
verb and noun and an adverb.   The topic could be whatever came up when the
coordinator hit it at a certain time.   And then make it 24 hours (perhaps
starting like a Friday midnight local Australia time??).   I actually like
the SCC as it was, but this is one way to do this scenario.

Post a reply to this message

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:406585c6$1@news.povray.org...
>
> > Fast render
> > Concern: Getting the vote formula "just right".
> True. Perhaps running a dummy contest first and try different formulas
> on the result and vote on which formula should be used.
>
>
> > Short time
> > Concern: Choosing a topic that minimises the chance of someone
> > having a scene already on hand.
> Additionally to a preclaimer like the IRTC one (image must be created
> for the contest), limiting the size of the file should be a good tool to
> keep the usage of already finished objects low.
> > Concern: Dealing with time zones.
> Don't think so. Either let the contest start two hours later each time
> (if it'll run several times) or choose a zone which covers most povers
> in a reasonable way (i.e. the competition falls for example somewhere
> from saturday morning 6am to saturday evening 12pm, which would cover
> already 18 hours).
>
>
> > Limited geometry
> > we assign a rating to each
> > primitive and the scene has to be built where the sum of the ratings
> > don't exceed some value.
> Or an approach like the one with the inverse time: You may use as many
> objects as you like but you're points will be divided by the amount of
> objects (may be interesting to also count for example macros, textures,
> etc.).
>
> > 3D fractals
> > Concern: These often require many primitives and therefore lots of
> > memory.
> Limit the memory: "Your scene is not allowed to use more than XX MB of
> memory. The value will be taken from the "peak memory" field of the
> render stats".
> > Concern: There may be some debate on whether some forms are fractal or
> > not.
> I would go for the fun and easy way here: It should look like a fractal.
> Letting only images of real fractals take part in the contest will IMHO
>
> IMHO combining some of these would be cool:
>
> "create an image which consists of a maximum of 10 spheres and 100 boxes
> which will render on <insert your machine here> in less than 1 hour. The
> scene may not contain more than 500 bytes and may not use any additional
> files. You got exactly 2 hours from 12:00 1st of April GMT."
>
>


Any time based contest limits people with older hardware. Sure, you can
preview things with low quality, no textures, etc. But someone with the
latest greatest 3GHz machine will have a testing turnaround time advantage
over me with my puny 3 year old mobile duron space heater.


ross.

Post a reply to this message

> Any time based contest limits people with older hardware. Sure, you can
> preview things with low quality, no textures, etc. But someone with the
> latest greatest 3GHz machine will have a testing turnaround time advantage
> over me with my puny 3 year old mobile duron space heater.

That is, of course, true. But you have to admit that this goes for every 
contest which has a deadline. With a 3Ghz monster you can create more 
complex (in means of render time) scenes. Even a two month period like 
the IRTC can be short if you wanted to do some great isosurface 
landscapes on a 800Mhz PC.
I agree that the difference is bigger when the deadline is shorter. 
There is however, always the possibility to do simpler scenes. Tek's 
winning image of the last round is a perfect example for that.
Additionally, the shorter the time, the less complex the entries will be.

I personally see no problem in a short deadline. I have to admit that 
I'm using an Athlon XP2600 with 1 Gig RAM, though :)

Florian

Post a reply to this message