> 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