"Warp" <war### [at] tagpovrayorg> wrote in message
news:4094f199@news.povray.org...
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Radiosity only. Not much description needed...
>
>   I actually like this one.
>
>   Defining the rules should be rather easy: Use of light_sources (and
> of course #includes) is forbidden.
>

I like this, in combination of using only one primitive type. say, a scene
of only spheres and radiosity. or boxes, or torus... Of course, you could
approximate a lot of things with clever CSG and boxes. But it would be more
clever to use something like a torus as your primitive type.

Post a reply to this message

On Sat, 01 May 2004 15:55:45 +1000, Paul Bourke <pdb### [at] swineduau>
wrote:
> I've run the short code and the fractal competitions, see
>   http://astronomy.swin.edu.au/~pbourke/povray/scc3/final/
>   http://astronomy.swin.edu.au/~pbourke/povray/povfrac/final/
>
> Are you sick of these competitions or is there still interest?

The only thing I do not like is end within weekend. To me best solution is to
end it on end of Monday so I can bring the entry I made during weekend. I have
less free time during weekend but more powerful CPU to play with. Last time I
spend two weeks gathering elements for fractal scene and finally realised it's
too late because I choosed wrong weekend :-(

> If the later then how about another in the near future, what about these options?
> 1. Limited geometry. eg: Create a scene with no more than 10 objects from
>    the following list: sphere, cylinder, cone, box....
                                                         .... POV-Logo

> Feel free to suggest others.

4. No programming. Create scene without #declaring, #whiling and #macroing
   anything with number of chars per object limited to 80 chars long single
   line. So the number of lines makes number of objects and no line is longer
   than 80-chars. This should extract power of some features as in shortes sig
   contest but without limitation to 4 lines.

5. Unrealistic parameters. Use at least one parameter in SDL in not suggested 
   way to make a key effect of the scene. Negative lightsource. Negative 
   radius etc. etc.

6. Playing with rays. Make the scene where image is created on surface after 
   reflection/refraction. Object in mirrors. Play of the light on glass. Hand 
   half under, half over surface of water.

I think that in general in your contests short code chould be favored in the
way size is not limited into exact number of chars but rather in relation to
other entries. So when the voting opens I would like to see percentage size in
relation to largest size in the contest round.

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:
> 4. No programming. Create scene without #declaring, #whiling and #macroing
>    anything

  Isn't that the exact opposite of what makes these small competitions
interesting?
  Why would it be interesting in *not* being able to use POV-Ray's full
potential in creating scenes?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <jjcf90po6amgjjeordn0i7t362t4dti70i@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> 4. No programming. Create scene without #declaring, #whiling and #macroing
>    anything with number of chars per object limited to 80 chars long single
>    line. So the number of lines makes number of objects and no line is longer
>    than 80-chars. This should extract power of some features as in shortes 
>    sig contest but without limitation to 4 lines.

All programming. No frame level objects, no background or sky_sphere. 
Result is something interesting in a generated file or debug stream.
Render time shouldn't be a problem with this one.


> 5. Unrealistic parameters. Use at least one parameter in SDL in not suggested 
>    way to make a key effect of the scene. Negative lightsource. Negative 
>    radius etc. etc.

One good example of this is newdiffract.pov. A completely unrealistic 
value of diffraction was used, with very colorful results.


> 6. Playing with rays. Make the scene where image is created on surface after 
>    reflection/refraction. Object in mirrors. Play of the light on glass. Hand 
>    half under, half over surface of water.

Similar to the "optics" competition I suggested.

Another idea: illustrate some mathematical concept or theorem. This one 
would give the competition some practical benefit...the people judging 
might learn something interesting.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On 4 May 2004 11:43:15 -0400, Warp <war### [at] tagpovrayorg> wrote:
> > 4. No programming. Create scene without #declaring, #whiling and #macroing
> >    anything
>
> Isn't that the exact opposite of what makes these small competitions
> interesting?

Not to me. The idea of the contest is to do unusual things. Of course I can
write program to output non-programming version of programming one but then it
will result in long source. The idea is to make source as short as possible so
flexibility of primitives/patterns/effects are better focused.

> Why would it be interesting in *not* being able to use POV-Ray's full
> potential in creating scenes?

That's the question you can ask about all the subjects. Why to force to write
short code if it's more readable in long form? Why to use only radiosity to
make a scene if similar effect can be rendered in short time using less
agresive radiosity + 2 light sources?

ABX

Post a reply to this message

in news:pdb_NOSPAM-E7E7D5.15554501052004@news.povray.org Paul Bourke 
wrote:

> Feel free to suggest others.
> 

How about the oldest subject in raytracing? Reflective sphere over 
checkered plane.

Ingo

Post a reply to this message

On Tue, 04 May 2004 11:51:58 -0400, Christopher James Huff
<cja### [at] earthlinknet> wrote:

>All programming. No frame level objects, no background or sky_sphere. 
>Result is something interesting in a generated file or debug stream.
>Render time shouldn't be a problem with this one.
>

Neat!  I like!  Hmm: write a uuencoded audio file? :D  :D



-- 
to all the companies who wait until a large user base becomes
dependant on their freeware, then shafting said happy campers with
mandatory payment for continued usage. I spit on your grave.

Post a reply to this message

Mischa wrote:
> Paul Bourke <pdb### [at] swineduau> wrote:
> 
>>1. Limited geometry. eg: Create a scene with no more than 10 objects from
>>   the following list: sphere, cylinder, cone, box.

All my shortest code contests were made that way - a forest made of 
three planes and a bunch of cylinders; a school of fish made with a 
lathe object and some disks, etc.

> But I like the idea with the tools, I've read here somewhere.

I've been working on a height field editor - would that count?

> ..) One (more or less simple) photo/image is given and each contestant tries
>    to reach the reference as close as possible only using PoV.
>    (The difficulty of this contest will strongly be influenced by the
> selected
>    picture of course.)

An architectural object of some sort would be neat (but may be very 
complex - like the U.S. capital building.)  But you'd want something 
like that which would allow POV to show it's stuff.

Another suggestion I liked was an animation contest.  You could limit it 
by size of POV source, or maybe limit what was being animated - the 
contest creator would create a basic scene - like a fountain, and the 
contestants would supply a macro that generates the water from the pipe 
and in the basin.

I missed the 3rd shortest code contest both because I wasn't online very 
much at the time, and thought it was limitted to 100 characters - I have 
enough trouble with 250!  Maybe next time....

Just had another thought - there was a coding contest I heard about once 
- the goal was to create a program the produced an animated fire. 
Perhaps something could be made from that.


Tom A.

Post a reply to this message

In article <4099245c.8811668@localhost>,
 pov### [at] bestwebnetalmost (povray) wrote:

> >All programming. No frame level objects, no background or sky_sphere. 
> >Result is something interesting in a generated file or debug stream.
> >Render time shouldn't be a problem with this one.
> 
> Neat!  I like!  Hmm: write a uuencoded audio file? :D  :D

Or an ASCII PPM file...
Hmm. Would it be considered sacrilege to write a scanline renderer in 
POV-Script?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message