Is it possible to submit old images ?

JC

Paul Bourke wrote:

> The first POVRay Fractal Raytracing Contest is now open, see
>    http://astronomy.swin.edu.au/povfrac/
> If you have a favourite 3D fractal and ideas on an elegant way
> to render it then maybe this contest if for you.


-- 
http://exether.free.fr/irtc (more IRTC stats !)

Post a reply to this message

Paul Bourke wrote:
> 
> The first POVRay Fractal Raytracing Contest is now open, see
>    http://astronomy.swin.edu.au/povfrac/

So, where the rules say "Include files are not permitted" does this
mean that TTF files are also excluded ?

Bernard

Post a reply to this message

> Is it possible to submit old images ?

There is no rule against it.
On the other hand, you might consider this a good opportunity
to improve a previous image.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

> > The first POVRay Fractal Raytracing Contest is now open, see
> >    http://astronomy.swin.edu.au/povfrac/
> So, where the rules say "Include files are not permitted" does this
> mean that TTF files are also excluded ?

Thanks, I've tightened that up

"The POVRay scene file entered must be totally self 
 contained and not rely on any external files."

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

> Wow, nice images. Immediately I want to see them in stereo.

Certainly I have an animation of the DLA image
   http://astronomy.swin.edu.au/~pbourke/fractals/dla3d/
at 1024x768 and in stereo, it is quite stunning. I can send you
a CD if you like with a mono animation of this and other movies 
in Quicktime (I have some CD's left over from a talk I gave recently).

> I'm sure you've done that. Are you willing to share some
> POV SDL? 

Most of those image examples are created using external programs 
that create the geometry, an are therefore mostly inellegible for
this competition :-). 
From the top
- fisheye image of 3D sponge, VERY old, actually rendered in Radiance
  but could easily be done in POVRay. Uses radiosity
  http://astronomy.swin.edu.au/~pbourke/fractals/gasket/spongeb.html
  ps: this was done back around 1990.
- DLA, this requires a rather numerically intensive program to
  create the data for POVRay.
- Wada fractals, the povray code is provided on the www page.
- Attractor, this is easy to create in POVRay and has been the
  discussion of many posts to the various povray news groups
  after I entered it in the SSC3
- Quaternion, easy in POVRay since it is one of the primitives
  provided.
- Applonian fractal, again requires a rather tricky piece of
  code external to POVRay to create the sphere positions.
-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

"The aim of this competition is to create a visually
compelling image of a 3D fractal form using the POVRay
raytacing program"

I would say this limits the acceptable software and the
required image far more strictly than the IRTC.  An IRTC
subjcet of "fractals" would surely accommodate anything from
a pure render of a 4d-julia to an imaginatively presented
close-up of the definition of the word "fractal" in a
rendered paper dictionary.  "Visually compelling" also seems
to exclude the possibility of a "technical merit" award as
per the IRTC for mere technical achievment.



>   Doesn't this replicate too much IRTC with a topic of
"fractals"?
> This is mainly because there are practically no limits on
what the
> user can do (except using external files, which isn't very
limiting,
> and a maximum of 10000 bytes, which isn't very limiting
either).
>
>   The problem I see with this is that there's really no
challenge
> in this competition other than making a beautiful image.
Which is
> exactly what IRTC is for.
>
>   (And of course how to define a "fractal" is another
question...)

"Warp" <war### [at] tagpovrayorg> wrote in message
news:406d5701@news.povray.org...
>   Doesn't this replicate too much IRTC with a topic of
"fractals"?
> This is mainly because there are practically no limits on
what the
> user can do (except using external files, which isn't very
limiting,
> and a maximum of 10000 bytes, which isn't very limiting
either).
>
>   The problem I see with this is that there's really no
challenge
> in this competition other than making a beautiful image.
Which is
> exactly what IRTC is for.
>
>   (And of course how to define a "fractal" is another
question...)
>
> -- 
> 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

In article <406d8791@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If they allow post-processing then it's not a rendering competition
> anymore. It's a computer graphics competition.

Depends on the type of post-processing. If it's done by hand, I'd 
disallow it. Otherwise, where do you draw the line? You can do 
rescaling, convolution filters, color adjustment, basically anything in 
POV-Ray, and some renderers have such features built in, which allows 
them to take advantage of data not available to external editors. It's 
an incredibly ugly hack, but it's possible, and no different from doing 
it in an external program.

So I'd say that this kind of full-image, non-interactive processing 
should be allowed, maybe with the requirement of the script or commands 
used to generate the final image. You can't really avoid it without 
carefully examining how the software generates each image, which may 
involve in-depth knowledge of how the software works internally. 
Interactive editing to remove rendering artifacts or add objects and 
details should not be allowed.

-- 
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

> >   If they allow post-processing then it's not a rendering competition
> > anymore. It's a computer graphics competition.
> Depends on the type of post-processing. If it's done by hand, I'd 
> disallow it. Otherwise, where do you draw the line? 

These are by no means easy questions especially for IRTC. For example,
entries using programs such as 3DStudioMax, Lightwave, Softimage, Maya,
etc may well have no "raytracing" involved and it would be pretty hard
to determine for sure if they did or not. Doesn't this make their entry
to the IRayTracingC problematic. Add to that the large degree of post
processing these packages allow, sometimes it is not even obvious whether
a rendering option is going to be performed as part of the rendering
(at least that aspect of rendering that involves analysis of the 3D
geometry) and which is post processing on the rendered image.

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Otherwise, where do you draw the line?

  At least I would disallow using an external image manipulation program
which is unrelated and separate from the renderer.
  For instance, if you render an image using POV-Ray as 10240x7680 and
then use Photoshop to rescale it to 1024x768, then that would be
forbidden because you are using an external program to modify the
image (potentially increasing its visual quality). The result would
not be the one produced by the renderer, but a modified one.
  This also disallows eg. brightness and contrast adjustments (currently
allowed). I personally think they should be forbidden anyways, because
they also produce an image which is not the direct result of the renderer
and can be used to enhance the visual quality of the image (specially
modifying the contrast of the image can produce quite stunning-looking
effects which the renderer might not be able to produce itself).
  If, however, the renderer *itself* can tune the brightness and
contrast of the result, then that would be ok (because it's a direct
output result of the renderer).

> So I'd say that this kind of full-image, non-interactive processing 
> should be allowed, maybe with the requirement of the script or commands 
> used to generate the final image.

  That way you could add all kinds of visual effects to the result
which are not produced by rendering, such as many types of motion blur,
glowing effects, etc etc.
  What you are getting is not what the renderer produces. The image made
by the renderer might look like crap, but after you apply all kinds of
special effects to the image it may look great. However, it's not a
rendered image anymore.

-- 
#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

Heckler <hec### [at] hotmailcom> wrote:
> I would say this limits the acceptable software and the
> required image far more strictly than the IRTC.

  I didn't say the competition is exactly like IRTC. I said that in
my opinion it replicates IRTC *too much* (even though it's not
identical). That is, it's just a competition on who makes the
prettiest image about a given subject. There's no real challenge
which would make it markedly different from the IRTC.

> "Visually compelling" also seems
> to exclude the possibility of a "technical merit" award as
> per the IRTC for mere technical achievment.

  There are three voting categories in the IRTC, but in practice they
have no meaning.
  I have seen way too many times people giving 20-20-20 to a
photorealistic image just because it looks so cool, no matter
how non-original and boring it is with regard to concept and
interpretation of the theme, for example (or giving 20 as
technical merit vote to an image which just uses some image
maps put onto a few polygons). And the other way around:
If an image looks like crap, it will not get a 20 eg. in
concept no matter how innovative and original the idea in
the image is.

-- 
#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