 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ChrisH" <lho### [at] comcast net> wrote:
> If the IRTC goes to a "pure" POVRAY rendering only format
I don't think this is ever going to happen - the IRTC was always exactly what
its name suggests, i.e. a competition/showcase for ray-traced images. One could
use any modelling tools to create the data, then any raytracer to render the
final image. There was never any specific focus on POV-Ray that I was aware of,
aside from the fact that because the competition was/is hosted by the POV-Ray
server there were more people in the POV-Ray community aware of it. And, to
start with at least, the new IRTC is likely to be dominated by POV-Ray users
simply because it's here that all the discussions have been taking place.
Highly placed entries generated by POV-Ray almost always employed external
modelling tools, so I don't think you have anything to fear on that count. :-)
As an aside, I really don't think we need to be that restrictive in the rules,
beyond insisting on the raytracing algorithm for the final render. Surely there
are enough experts involved to spot abusers and cheaters? Especially if thorough
image documentation (and, ideally, source files) are encouraged.
I think Warp's point about post-processing is a little more problematic
(although his example of antialiasing is not something I personally would
object to - in many cases, it can be faster to render large and jaggy than
smaller and with aa, to the extent that to do the latter might cause one to
miss the submission deadline!).
In any case, it's good to see so many IRTC veterans voicing their opinion here.
I look forward to seeing everyone's work in future rounds. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> >
> I certainly do agree with what you are saying here. However, as an aside, I
> must say (and this is really personal) that the technical side is only a
> 'tool' for me to achieve my art. For me, it is not an end in itself, however
> interesting and important it may be otherwise. I must admit that if the
> main(?) focus of the IRTC is the technical focus, then I sadly loose
> interest. I thought that the IRTC was a platform to create (and show)
> beautiful images through ray-tracing, whatever the technical background.
>
A pure coding contest is not for me either.
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
....I
> must say (and this is really personal) that the technical side is only a
> 'tool' for me to achieve my art. For me, it is not an end in itself, however
> interesting and important it may be otherwise. I must admit that if the
> main(?) focus of the IRTC is the technical focus, then I sadly loose
> interest. I thought that the IRTC was a platform to create (and show)
> beautiful images through ray-tracing, whatever the technical background.
and
If, however, the consensus
here that that is not allowed, then I see no future (for me) in the IRTC
anymore... :-)
I agree 100%. Same for me.
The process of making a beautiful image in Povray takes a bit more than
technical ability and usually demands more tools than one. I have always seen
participating in the IRTC as an place where you can learn a lot and at the same
time share your techniques. I work in more than one 3D software and sometimes
the execution of an particular idea is better suited to one program than the
other. Sometimes I use more than one in unison. We all do!
The misconception that working in a commercial software is easier than in a
non-commercial also seems to be widespread. I must admit that my learning curve
was steep at the beginning, but when you master one program to some degree, it
point in making people assume that making a beautiful image in any 3D
trial and error and hundreds of test renderings to find out what works and what
does not. Until, of course, when you reach the point that you have done it all
To me the IRTC has been the platform where I could challenge myself and try out
new ideas and techniques. A place where I can have my peers judge my work and
push me to go for a bigger challenge each time. This has been very rewarding
because after all, the voting system seems to be fair and helpful. If you get a
low score, then you know what to do. Push your boundaries and try harder next
time. It works.
Hildur K.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
1) You can use any tool to generate your model and textures. POV-coding is not
required but is preferred.
to.
3) You must do the rendering in POV-Ray (Should this be with radiosity turned
on?)
4) You may not do any post-production on the final image or animation
(I presume this applies to animations as well with the exception of something to
Anyone object to these guidelines or want to add anything else?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Jun 2009 15:30:39 -0400, Michael Hunter wrote:
> It feels to me that theres been a consensus:
>
> 1) You can use any tool to generate your model and textures. POV-coding
> is not required but is preferred.
> 2) 2D texture maps are ok provided that theres a bunch of geometry
its
> mapped to.
> 3) You must do the rendering in POV-Ray (Should this be with radiosity
> turned on?)
> 4) You may not do any post-production on the final image or animation
>
> (I presume this applies to animations as well with the exception of
> something to glue the frames together since POV-Ray wont do that.)
>
> Anyone object to these guidelines or want to add anything else?
This seems pretty consistent with the guidelines from the past, as I'm
generally a non-submitter, this looks good to me. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> As a completely personal opinion, I think *any* kind of post-processing
> of the rendered image is cheating, or at least can be used for cheating.
>
> For example, the old IRTC allowed resizing the rendered image as a post-
> processing step. Some people abused this allowance to cheat and get a much
> higher-quality antialiasing than what the renderer was able to produce all
> by itself (by rendering a very large image and then using a 2D software to
> scale it down by averaging pixels, resulting in high-quality antialiasing,
> which was *not* the product of the renderer).
my personal opinion on that matter: This example sounds perfectly
acceptable to me and could also be used to argue the point that it
should be allowed to do more post-processing.
If the above procedure actually has a better ratio of quality
per render time than other anti-aliasing methods one might be
allowed to ask: Why isn't the method built into the renderer?
Maybe it wasn't felt worth the development time because it is
so simple to do as a post-processing step? That would lead to
a somewhat circular argumentation.
Also, if I now build my own patched version of the renderer which
implements this anti-aliasing method, is it suddenly ok to use it
because it is now longer a separate post-processing step? What
about using MegaPOV which also has some post-processing?
Most global 2D effects could conceivably be implemented in SDL
with multipass renders and evaluating pigments of the input image.
Does this make it any more or less cheating?
My recommendation would be to allow any kind of post-processing
which is of a "general" nature, that is, a global effect which can
be meaningfully applied to any image. Naturally this excludes any
manual editing of portions of the image, say, using a brush.
However, I think it should then be mandatory that the image
description lists all post-processing steps which were used.
> This principle would of course allow extreme #3 to be submitted.
> However, it's then up to the judges to vote it down because there
> was no real 3D modelling involved.
Similarly, people could vote done images due to excessive
post-processing if they feel someone abuses relaxed rules.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Hunter wrote:
> 3) You must do the rendering in POV-Ray
I don't think anyone said that. Any raytracer should be allowed.
However, there seems to be a controversy regarding the use of other
render technologies, such as scan line rendering. I'm not really sure
if that would be a bad thing or a good thing, however, the IRTC would
need to be renamed if this changes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Michael Hunter wrote:
>
> > 3) You must do the rendering in POV-Ray
>
> I don't think anyone said that. Any raytracer should be allowed.
Agreed. That certainly wasn't true before, and I'd be shocked if it became true
now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Jun 2009 00:57:45 +0200, Christian Froeschlin wrote:
>> 3) You must do the rendering in POV-Ray
>
> I don't think anyone said that. Any raytracer should be allowed.
Missed that one myself, and I would agree with you - it's not the IPOVC,
it's the IRTC. As such the charter is broader than POV-Ray.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Michael Hunter wrote:
> >
> > > 3) You must do the rendering in POV-Ray
I went to see on the IRTC stats page and read through several documentations on
the top ten group. I was quite surprised to see how many top rated submissions
were rendered... sorry, raytraced using Megapov! What is Megapov anyway? A
of Povray?
And I agree with others here. There are a many great raytracers around and no
need to get bitchy about what people choose to experiment with.
algorithm really is. Can I put it on my pasta?
Hildur
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
