"clipka" <nomail@nomail> wrote:

> > no external data files, no image maps, no multipass renders, and
> > of course absolutely no post-processing except jpg conversion.
> > Source code would be mandatory for purist images and the highest
> > ranking purist image gets an honorable mention ;)
>
> Yeah, but bloody likely nothing more than that :P

Couple of days ago I took a quick took: the top 10 winners of the IRTC used
various tools to generate their images in their many submissions. Here is a
list of the main software used by these successful participants (macros are not
listed here).

Povray
BMRT
3ds Max
Mental Ray
Arboretum Forester
Blender
MakeHuman
Plant Studio
Megapov
mlPov
Hamapatch
Leveller
Poser
Amapi
Autocad
Texture Magic
Terragen
Win 3d
Crossroads
Wings 3D
Rhino 3D
Spatch
Paintshop Pro
DazStudio
Photoshop
World Machine
3d studio
Moray
Illustrator
bCad
Gforge
Blob Sculptor
HF-Lab
ZBrush
The Gimp
UniMegaPov
Poseray
Xfrog
Tree Professional
Quick 3D
Clothray
Corel Photo Paint
Corel Draw
PovMan
RibTickler
Picture Publisher
Pov tree
UV mapper
Meshcomp
Arbaro
Kwrite

I only checked ten people, there is probably much more.



Hildur

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Allow change C:Image->Image if there exists f:RGB->RGB
> with f(I(x,y))) = C(I)(x,y) for each location (x,y)?

  You could do anything with such a function, such as draw lines, etc.

-- 
                                                          - Warp

Post a reply to this message

Christian Froeschlin wrote:

> Maybe the IRTC should allow tagging a submission as "purist".
> That would be restricted to images created using an officially
> released version of a raytracer, using pure code, no modeller,
> no external data files, no image maps, no multipass renders, and
> of course absolutely no post-processing except jpg conversion.
> Source code would be mandatory for purist images and the highest
> ranking purist image gets an honorable mention ;)

What if the image maps are generated by the ray tracer?

What if the external data files are likewise generated?

What if the post-processing is done by the renderer?

I don't see how combining the results of several POV-Ray renders into 
one final image is less nearly "pure" POV-Ray than the alternative you 
suggest.  I would argue that it is more nearly pure, and not less, 
because it uses POV-Ray to do what is ordinarily done by other applications.

Regards,
John

Post a reply to this message

John VanSickle wrote:

> What if the image maps are generated by the ray tracer?

well, the "no multipass" rule was basically indended to prevent
2d-ish after-effects. Any such effect could be implemented by loading
the image from the first pass, evaluating its pixels one-by-one,
performing any image processing on the pixel array,  recreating
a pigment and applying it to a plane.

 > What if the external data files are likewise generated?

No objections and can be done at the beginning of a single
pass render without problems (at least in POV-Ray). Also, as
long as the scene is capable of render in a single pass, I
don't think there would be objections to also include a
flag to reuse the data file for efficiency when
tweaking renders, as with photon map data.

 > What if the post-processing is done by the renderer?

Not sure what kind of post-processing is supported by raytracers
out there. But I suppose most likely candidates interested in the
"purist" category would be POV-Ray users anyway ;) And MegaPOV's
post-processing features were the reason I suggested "purist"
images should use an *official* release.

Post a reply to this message

clipka wrote:

> Hmm... what if that particular raytracer had an integrated modeller??

If it's by design an environment which requires you to model
interactively the tool might not qualify for "purist" entries.

> And what would stop me from modelling a mesh in Wings3D, exporting it,
> reformating it, and claiming that I'd hacked That Mesh2 Code up myself? Who the
> * could tell (or rather, prove)?

well ... not exactly prove ... but try submitting an include file
with a 20,000 vertex mesh as "purist" claiming it's handwritten and
see how voters take to it ;)

Actually, I wouldn't be worried about cheating in the "purist"
category anyway. It's too restricted to plausibly cheat in such a
scope that you have a chance of winning the overall competition, and
winning must be very important to someone who considers cheating.

Post a reply to this message

Bill Pragnell wrote:

> I wonder, could my meshrelief macros be used to generate .inc
> files for this scenario? It is a multi-parse, if not a multi-pass render...)

I didn't look at the code yet, but I'd expect you can write
the file at the beginning and #include it later within a single
pass, so I'd say it qualifies.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Bill Pragnell wrote:
>
> > I wonder, could my meshrelief macros be used to generate .inc
> > files for this scenario? It is a multi-parse, if not a multi-pass render...)
>
> I didn't look at the code yet, but I'd expect you can write
> the file at the beginning and #include it later within a single
> pass, so I'd say it qualifies.

Yes, that's true, I hadn't thought of that. I usually render at the same time to
make sure it's a decent mesh that's been saved...

There's no way to tell anyway, it gives exactly the same results, just parses
quicker.

Post a reply to this message

Tek wrote:

> 
> 
> The premise of your argument seems to be that you want to expand the range 
> of people interested in entering this contest. I have to disagree with that 
> principal. One of the main reasons I have found the IRTC so rewarding is the 
> very technical focus of most entrants and judges. If it loses that focus, if 
> people start commenting on my povray images talking about shaders and 
> polygons, I'm going to lose interest.
> 

I don't think reexamining the rules will change that.

I think the thrust of Michael's question is actually more in line with 
your sentiments than you seem to realize.  I think he is trying to 
discuss how, for instance, some of the very exciting new techniques that 
have shown up on the ng's lately, involving the use of forward 
raytracing together with distribution of workload over multiple cores, 
but which requires the recompositing of images, might be recognized and 
explored.  Surely these innovations are all about the technical side. 
And what if such innovations turn out to facilitate the use of such 
brilliant and POV-centric techniques like isosurfaces?  All he is saying 
is that these surprising innovations can lead to perhaps even more 
surprises.  And the driving force here is still very, very techical.

The fact is that cg is still in a technical phase.  The day when 
conceptual plays on process, when its aesthetic artifice will be 
deconstructed etc. is mostly still in the future.  And the form that 
will take still largely unknown.

The IRTC will still attract the same people.  This is not the place 
where the guy or gal with strong figurative ability morphing comic book 
mosnsters in a professional piece of software will want to make his/her 
mark.  The taste for exquisite lighting, subtle reflections, quirky 
scene-building, and the atom-cracking collision of classical math with 
the chaos of grunge, is what reigns here.  But we don't need to limit 
the technical means to get at that.  Rather we need to encourage such 
innovation.

This could be the place, (doubtful but possible,) in some distant time, 
when the artist doing some cg equivalent of Sherrie Levine 
re-photographing Walker Evans, might be shown and understood.

Post a reply to this message

Christian Froeschlin wrote:
> John VanSickle wrote:
> 
>> What if the image maps are generated by the ray tracer?
> 
> well, the "no multipass" rule was basically indended to prevent
> 2d-ish after-effects. Any such effect could be implemented by loading
> the image from the first pass, evaluating its pixels one-by-one,
> performing any image processing on the pixel array,  recreating
> a pigment and applying it to a plane.
> 
>  > What if the external data files are likewise generated?
> 
> No objections and can be done at the beginning of a single
> pass render without problems (at least in POV-Ray). Also, as
> long as the scene is capable of render in a single pass, I
> don't think there would be objections to also include a
> flag to reuse the data file for efficiency when
> tweaking renders, as with photon map data.
> 
>  > What if the post-processing is done by the renderer?
> 
> Not sure what kind of post-processing is supported by raytracers
> out there.

For POV-Ray, it is as simple as pigmenting a polygon using a combination 
of two or more image_maps, these being taken from frames rendered 
earlier.  The different effects that can be achieved this way are quite 
varied.

I have done masking in several of my IRTC animations, using POV-Ray to 
combine two images and a mask to make the final image.  Here is a 
description of what I did in my latest judged animation, "Getting It 
Online":

------------------------------------

"The shot in which Boxer accesses the video stream from the club is 
probably the most complicated job of compositing that I've done so far. 
  It went like this:

1.  I modeled a scene of a caseless ladybot going around the brass pole 
in the strip club.

2.  I rendered four seconds worth of frames at 320x240.

3.  I rendered the same frames a second time at 40x30 (1:8 sampling in 
both directions).

4.  I modeled a masking scene for the parts that are supposed to be 
digitally censored; this mask consisted of the container shape for the 
part that needed to be censored, textured solid white, with nothing else 
in the scene, and a black background.  I animated the container exactly 
as the uncased portion of the caseless ladybot, and animated the camera 
exactly as in the scene modeled in step one.

5.  I rendered the masking scene at 40x30 for four seconds of frames.

6.  I did another scene, in which a small rectangle was textured with a 
     pigment equal to A*B+C*(1-A), where A is the 40x30 render of the 
scene, B is the white portion of the mask, and C is the 320x240 render 
of the scene.  This scene also had the titling 
"www.TheSilverCircuit.xxx" and other stuff in it.

7.  I did another scene for the "Buffering..." screen.

8.  The frames from steps 6 and 7 were used as the pigmenting for 
Boxer's computer screen.

---------------------------

Possibly some of the steps that made use of earlier renders could have 
been rendered directly, but this was certainly not always the case.

In all of my animations involving a Greb ship flying into or out of a 
wormhole ("Cliff Hanger," "A Narrow Escape," and "News from the Front") 
I used masking to achieve the desired effect.

I've done several kinds of fades, by combining two sets of rendered 
frames using a pigment pattern, with the indexes in the pigment map 
shifting over time.

I have rendered frames for an animation a rate of 240n frames per second 
and averaged together bunches of n to make motion blur.

I've also used rendered frames as the image for video displays in 
animations as well.

Regards,
John

Post a reply to this message

John VanSickle wrote:

>> Not sure what kind of post-processing is supported by raytracers
>> out there.
> 
> For POV-Ray, it is as simple as pigmenting a polygon using a combination 
> of two or more image_maps, these being taken from frames rendered 
> earlier.

Yes, I probably should have said "is supported by *other*
raytracers except the one I know" ;) And I was thinking more
about built-in postprocessing which could be argued to work
in a single pass (such as post_process {} in MegaPOV) to
circumvent a no-multi-pass rule for a "purists".

Post a reply to this message