> >  Well, I think he has to put some upper limit for practical reasons.
> > If each entry would take 24 hours to render (at 800x600 with antialiasing),
> > rendering all the entries would take as many days as there are entries... :)
> Isn't there ren### [at] paulbourke ?

Yes there is and it will be used if necessary.
Anyone who submits something that takes 200+ processors more than a 
couple of hours probably hasn't rendered the image themselves.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

> > Please don't be too strict there, my current WIP takes about 5 hours at 
> > 320x240, no aa on an Athlon 1GHz.

You guys are scaring me.

>   Well, I think he has to put some upper limit for practical reasons.
> If each entry would take 24 hours to render (at 800x600 with antialiasing),
> rendering all the entries would take as many days as there are entries... :)

They will be rendered as they are submitted so that might help a bit.
I have also allocated 5 days from the end of contest closure to the
start of the rendering.

I'll think about a limit, one possibility is to say "rendering will
start as soon as the entry is received, it must finish before the
voting starts".
-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

>   By the way, perhaps you should mention in the page the exact rendering
> settings you will be using to render the images (the command-line options
> should suffice).
>   If you have a fast machine, I propose rather good-quality settings
> (mainly with regard to antialiasing, something like "+a0.1 +am2").

The current (minimal) ini file is

Output_File_Type=C
Width=800
Height=600
Quality=9
Antialias=on
Antialias_Threshold=0.01

If people have special requirements (radiosity, oh no!) then
I will consider them. The jpg is made with "convert" with quality
set to 95%.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

> Complaint: 256 chars is too short. I would like to have the original (?)
> 500 at my disposal. Please let's turn this into a LONG code contest... ;-)

I first thought that also but I have managed to create what I
think are very artistic images with as little as 180 bytes.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

Paul Bourke <pdb### [at] swineduau> wrote:
> If people have special requirements (radiosity, oh no!) then
> I will consider them.

  Radiosity is not turned on by ini file settings in POV-Ray 3.5 and later
but from the scene itself, so you don't need to worry about that.

> The jpg is made with "convert" with quality
> set to 95%.

  I think that the proposal of the participant accepting the image being
a good idea. Sometimes some patological images will have artifacts even
at 95% jpeg quality and require additional jpeg setting tweaking (namely
setting the color sampling to 1x1x1).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Sun, 08 Feb 2004 22:13:05 +1100, Paul Bourke
<pdb### [at] swineduau> wrote:

>Consider the POVRay Short Code Contest round 3 (SCC3) open!
>The beginnings of the www page is here
>    http://astronomy.swin.edu.au/scc3/
>It will evolve as time goes on. If you have any suggestions,
>corrections, complaints (surely not), then feel free to
>email me or post them here for debate.
>
>The submission page is working although it hasn't been stress
>tested, so be gentle.
>-- 
>Paul Bourke
>pdb_NOSPAMswin.edu.au

	I went to the page and read all of the details.
	I have a concern.
	The page says that the entries will be rendered using
version 3.6.  Seeing as how 3.6 is still beta, with potential
for instabilities, maybe using a beta for contests is not a
good idea.

Post a reply to this message

nospam wrote:

> 
>         I went to the page and read all of the details.
>         I have a concern.
>         The page says that the entries will be rendered using
> version 3.6.  Seeing as how 3.6 is still beta, with potential
> for instabilities, maybe using a beta for contests is not a
> good idea.

Judging by the extremely low number of bugs reported in the first two
weeks of the beta testing I would venture to say that v3.6b1 appears
to be very stable.

-- 
Ken Tyler

Post a reply to this message

>         I went to the page and read all of the details.
>         I have a concern.
>         The page says that the entries will be rendered using
> version 3.6.  Seeing as how 3.6 is still beta, with potential
> for instabilities, maybe using a beta for contests is not a
> good idea.

Part of the idea for running the contest was to "celebrate"
the 3.6beta1 release. I don't want to relax this if I can help
it, it would make my automatic processing of the entries much 
more problematic. After all, some people might submit code that
exploits a bug....?

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

nospam <Pet### [at] nymaliasnetalmost> wrote:
>         The page says that the entries will be rendered using
> version 3.6.  Seeing as how 3.6 is still beta, with potential
> for instabilities, maybe using a beta for contests is not a
> good idea.

  In my opinion it's an excellent idea. It's a wonderful testbed to
really stress POV-Ray 3.6 with unusual code, which potentially will
cause discoveries of bugs.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Just submitted my 242 byte baby. 256 bytes are really something that
makes you're life hard, especially with long keywords (global_settings 
etc...), but it makes it reallly interesting, too!

Can't wait to see the other submissions. Good luck to everybody :)

Florian

Post a reply to this message