 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Jun 2009 20:16:32 -0400, Hildur K. wrote:
> What is Megapov anyway? A different software with it´s own functions or
> just a slightly altered compile of Povray?
http://megapov.inetart.net/
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hilder K Wrote:
>"no need to get bitchy about what people choose to experiment with."
Well... that was my point in the first place. Let people do what they do and
give them the feedback you want to give. Freedom of speech. As long as it's
meaningful in a 3D context because that's what we're talking about (not just
raytracing but modeling, environmental settings, texture maps etc)...
So the bottom line is after 50+ postings in the last few days that everything is
perfect the way it has always been. Right? No one sees a problem other than me?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Hunter wrote:
> be considered minimum requirements for the competition. It has been taken over
> remains. We will fail to retain and acquire the most proficient 3D artists if
> we dictate to them how they are allowed to make their art. These people both
> inspire us with their images and teach us with their comments and should be
> highly valued.
>
> I have argued that we have arrived in this situation because the initial rules
> techniques have been developed that while powerful are in opposition with the
> initial rules. I believe the intent of these rules were to focus work and
> conversation about the creation of 3D images and animations. This is the sole
> intent and we should update the rules to reflect this just as the web site has
> been updated. I have suggested the following as the minimum requirements for a
> submission to the IRTC for your consideration:
>
>
> The issue of a particular image or animation showing a good use of 3D is a
> matter I think is best left up to judging and comments and to be done on a case
> by case basis. Whereas the minimum requirements should only be used to maintain
> the focal point on 3D work. Nothing more.
>
> I would greatly appreciate your thoughts on this. It has either been accepted by
> people here or was ignored because I write to much.
>
>
>
I guess I have a couple of reactions.
First, what minimum requirements are you so worried about? Are these
posted on the new site somewhere? (I tried to check, but, as usual, I
forgot my password.) I would be interested in the particular limitations
you are reacting to and citing in your historical view.
Your question is seriously posed (twice!) and therefore deserves some
attention.
I agree with your position although:
1. not always for your reasons, and
2. it flies in the face of some personal creative sentiments.
I recognize that a contest with imposed limitations might discourage
some possible participants. I also recognize that those same
constraints might reassure others or even challenge some to greater
exertions. The povcomp, with its requirement that code be submitted to
verify the render, was certainly proof of the viable use of constraints.
What bothers me about both imposed limitations, and attempts to
strategically loosen them, is my desire, echoing Warp, for as much
logical consistency as possible. But I end up with a different conclusion.
I think that your formulation provides the best consistency by proposing
an uncompromising credo of inclusion along with a general statement of
direction. I think the boundary cases described by Warp do mount a
serious critique of your position, particularly your reliance on "3D" as
a term commonly understood, but I think that that needs to be risked in
order to gain the intellectual and creative vitality which stems from a
credo of inclusion.
Now my personal sentiments are more aligned with Warp's. There is an
intuitive purity to drawing the line at single-pass rendering with a ray
tracer, using the ray tracer only, with no post-processing. A relaxed
version of this standard, (which allows varous means for producing
objects,) I have continued to impose on myself. It is aligned with my
own understanding of the internal constraints necessary for producing
and understanding art. And Warp's chronicling of the exploitation of
certain 'allowances' in the past makes a strong case for having an
absolute 'no post-processing' limitation. But it equally demonstrates
the artificiality, and internal contradictions of any imposed
limitations. And ultimately, single-pass rendering is an artificial
limitation too, an artifact, as you suggest, reflecting the technical
outlook at a earlier point in time. So I agree that, while useful, it
is a standard that should not be enshrined in contest rules. Instead
let the experiment proceed unfettered, and the chips fall where they
may.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Jun 2009 21:50:41 -0400, Michael Hunter wrote:
> So the bottom line is after 50+ postings in the last few days that
> everything is perfect the way it has always been. Right? No one sees a
> problem other than me?
Of course there's generally always room for improvement, however what's
in place has worked for a fairly long time, so there would need to be
some really significant deficiency reason for a change to be made, IMO.
But at the same time, it is also important to remember that this
competition wasn't originally framed as a POV-Ray only competition.
Trying to turn it into one is likely to result in some pushback from
people using other tools, and that's only natural.
But I don't think that it's reasonable either to take an absolutist
position like you are in your last post - "either everything is fine the
way it is" or "there's a problem that needs to be addressed by
overhauling the entire premise of the competition".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> 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?
IIRC, there was a particular entry where the entrant coded his own
raytracer because a feature he wanted wasn't available in any other.
I'm perfectly fine with that, as long as your code changes are available
for others to use.
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> I thought that the IRTC was a platform to create (and show)
> beautiful images through ray-tracing, whatever the technical background.
That's exactly what it is. The rules, as they were originally
envisioned, were created to restrict it to raytracing, however, rather
than being a Poser or Photoshop or any-CG-at-all competition.
This isn't a technical POV coding challenge. It isn't a general POV-Ray
competition, or even "POV & Friends."
It's raytracing.
As long as the main image creation is done via raytracing, most people
will overlook a few minor tweaks. For instance, gamma adjustment is
usually OK, adjusting color balance on several separate layers in
Photoshop is probably not.
Likewise, using a program like Moray to model a scene and export it to
POV is OK; positioning figures in Poser and exporting them to your
favorite raytracer is OK; rendering a scene using the scanline renderer
in Blender is not.
Does that help?
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Hunter wrote:
> 1) You can use any tool to generate your model and textures. POV-coding is not
> required but is preferred.
Officially, POV isn't preferred. Technically, many judges (remember,
though, it's the entrants themselves who do the judging!) prefer POV
because they're more familiar with it, and so they can more easily judge
an author's effort and skill.
> 3) You must do the rendering in POV-Ray (Should this be with radiosity turned
> on?)
Wrong. The rendering must be raytraced. There are now literally dozens
if not hundreds of free raytracers you may use. POV is popular not
because the IRTC supports it in any way, but for precisely the opposite
reason: POV supports the IRTC. A large portion of the community is
introduced to the IRTC as "the" place to challenge yourself. No other
raytracer that I know of promotes the IRTC this heavily; thus, the
apparent (but nonexistent) bias.
> 4) You may not do any post-production on the final image or animation
Post-production which is general in nature is usually accepted, that is,
if the same operation is done to every pixel (like gamma correction).
Post-production used for artistic purposes, like color balance or focal
blur, are more controversial.
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Hildur K." <hil### [at] 3dcafemail every1net> wrote:
> algorithm really is. Can I put it on my pasta?
Not a good idea. You might end up with...
http://en.wikipedia.org/wiki/Spaghetti_programming
;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> 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.
Then the IRTC becomes just another Photoshop contest site. Boring.
> 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?
Irrelevant. If the renderer doesn't support it, then it doesn't. The
reasons are rather irrelevant in this.
> 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?
Yes. It's the direct output of the rendering software, not the direct
output of Photoshop or Gimp.
> 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?
Yes, because it's the result of a rendering software, not the result of
an image manipulation software.
> My recommendation would be to allow any kind of post-processing
> which is of a "general" nature
That's the problem: Defining what's allowed and what isn't becomes
really complicated, and you end up with a rule book thicker than the one
in Formula 1 racing. Don't you think *that* is going to discourage people?
The rule "no post-processing with external software allowed, period"
is simple and straightforward.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Then the IRTC becomes just another Photoshop contest site. Boring.
knowing the difference between a painted image or a photo or a raytraced image,
or can they easily be fooled?
Here is a quiz where people can test their capabilities to tell the difference?
http://dac.escet.urjc.es/rvmaster/rm/
> > 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?
>
> Irrelevant. If the renderer doesn't support it, then it doesn't. The
> reasons are rather irrelevant in this.
The reason for aliasing is usually shortcomings in the software and/or hardware.
It has nothing to do with the actual capabilities of the artist. If the
rendering. Then we have an absolute beginner. Some scenes are difficult in this
regard, others are easy. If this can be solved in a quick and effective manner,
then it can save people enormous render times. Not everybody has an extra PC to
use while the other one is occupied doing a three week render. Is that
irrelevant?
Is it illegal to render big and then scale the image down? Because in the past
people did recommend that to me in comments, on a scene with a difficult AA
situation. Is it?
>
> > 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?
>
> Yes. It's the direct output of the rendering software, not the direct
> output of Photoshop or Gimp.
If I do gamma corrections and add my name, is it then still a direct output from
the rendering software?
Is adjusting Levels a acceptable method of gamma correction? Because in PS,
there is no button named "gamma". Or should I stick with Brightness/Contrast?
> > 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?
>
> Yes, because it's the result of a rendering software, not the result of
> an image manipulation software.
> > My recommendation would be to allow any kind of post-processing
> > which is of a "general" nature
>
> That's the problem: Defining what's allowed and what isn't becomes
> really complicated, and you end up with a rule book thicker than the one
> in Formula 1 racing. Don't you think *that* is going to discourage people?
Not necessary to make it thick. Simply make a short list of allowed effects. The
rule of thumb could be (like it already is) that the process should affect every
pixel in the image. Then you could write down several options, like scaling,
blurring, gamma (how?), color correcting etc. How about glow? That is a post
effect in some raytracers.
>
> The rule "no post-processing with external software allowed, period"
> is simple and straightforward.
And often a liability and restriction to people who want to utilize the utmost
capabilities of the renderer, but have to choose between
reflections/isosurfaces/focal blur/radiosity and whatever, simply because you
The bottom line is that people using Povray should be very eager to change the
many of advanced processes almost demand you to have a supercomputer. Give
Hildur K.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
