 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's a good question. I just downloaded a PovRay GUI Extension the
implimented motion blur. My question is this... would it be a violation
of rules (more specificly the post-processing one) to use this in an
animation or still.
It was the DigiTape extension.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doug n' Dinsdale wrote:
> Here's a good question. I just downloaded a PovRay GUI Extension the
> implimented motion blur. My question is this... would it be a violation
> of rules (more specificly the post-processing one) to use this in an
> animation or still.
>
> It was the DigiTape extension.
I hate to be the voice of gloom but it would seem to me that although
the implementation is different it is very much like the many image
filtering effects tools used in paint programs. If you could utilize
the blurred images to produce an animation it still is using post
image manipulation for an effect that was not an implemented feature
of the raytracing package you are using. The intent of the rule is to
cause you to use your skills and imagination to get the effects you
need using the software provided and features of what that software
provides. Many raytracing effects can be simulated in 2D paint packages
but are not what the irtc is all about.
These are my opinions and yours may very.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not actually doing a scene that involves motion blur, I was just
wondering. The other side of the coin then is what about a patched version of
povray (ie source code modifacation) as there was a scene (admitedly stills)
that I belive won a round. What is the difference between a GUI Ext and a
source mod, besides the obvious.
I respect your opinion but I just feel that this question needs answering now
before it becomes a problem.
Ken wrote:
> Doug n' Dinsdale wrote:
>
> > Here's a good question. I just downloaded a PovRay GUI Extension the
> > implimented motion blur. My question is this... would it be a violation
> > of rules (more specificly the post-processing one) to use this in an
> > animation or still.
> >
> > It was the DigiTape extension.
>
> I hate to be the voice of gloom but it would seem to me that although
> the implementation is different it is very much like the many image
> filtering effects tools used in paint programs. If you could utilize
> the blurred images to produce an animation it still is using post
> image manipulation for an effect that was not an implemented feature
> of the raytracing package you are using. The intent of the rule is to
> cause you to use your skills and imagination to get the effects you
> need using the software provided and features of what that software
> provides. Many raytracing effects can be simulated in 2D paint packages
> but are not what the irtc is all about.
>
> These are my opinions and yours may very.
>
> Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doug n' Dinsdale wrote:
>
>The other side of the coin then is what about a patched version of
> povray (ie source code modifacation) as there was a scene (admitedly stills)
> that I belive won a round. What is the difference between a GUI Ext and a
> source mod, besides the obvious.
>
I would say that the core of the question should be if the effect was
created by the means of raytracing or by the means of postprocessing (in
other words by changing a already raytraced picture). A modification of
the raytracer respects this because it is *not* modificating a existing
picture but modificating the output. That this might not be fair in the
terms of competition is another problem. This must be respected by the
voters.
This is my personal opinion, yours might differ!
With regards,
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well stated.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Indeed, there was an image that won that was rendered using a patches version of
POV-Ray that used a post-process effect. The program effectively rendered
multiple frames, held them, then averaged them to create the final image. So the
main difference between a GUI ext and a source mod may be as simple as what the
rules explicitly tell you. Too be honest, the administrators really wouldn't do
anything IMO if you use your extension. It's just a matter of how the judges
feel, and there's no real way to be sure of that since it changes every round.
-Mike
Doug n' Dinsdale wrote:
> I'm not actually doing a scene that involves motion blur, I was just
> wondering. The other side of the coin then is what about a patched version of
> povray (ie source code modifacation) as there was a scene (admitedly stills)
> that I belive won a round. What is the difference between a GUI Ext and a
> source mod, besides the obvious.
>
> I respect your opinion but I just feel that this question needs answering now
> before it becomes a problem.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been told that any process that affects the whole pic is acceptable
i.e sharpening, auto equalization etc.
Mick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doug n' Dinsdale wrote in message <364FF2DA.B4E60860@networx.net.au>...
>I'm not actually doing a scene that involves motion blur, I was just
>wondering. The other side of the coin then is what about a patched version
of
>povray (ie source code modifacation) as there was a scene (admitedly
stills)
>that I belive won a round. What is the difference between a GUI Ext and a
>source mod, besides the obvious.
>
>I respect your opinion but I just feel that this question needs answering
now
>before it becomes a problem.
Can't you model it directly as an object? I am working on a still that has
motion blur, and
it is done by using multiple transparent copies of an object. Sure it takes
longer to render,
but it is completeley POV (no patches even) and doesn't require any extra
software
Chris Jeppesen
>
>Ken wrote:
>
>> Doug n' Dinsdale wrote:
>>
>> > Here's a good question. I just downloaded a PovRay GUI Extension the
>> > implimented motion blur. My question is this... would it be a violation
>> > of rules (more specificly the post-processing one) to use this in an
>> > animation or still.
>> >
>> > It was the DigiTape extension.
>>
>> I hate to be the voice of gloom but it would seem to me that although
>> the implementation is different it is very much like the many image
>> filtering effects tools used in paint programs. If you could utilize
>> the blurred images to produce an animation it still is using post
>> image manipulation for an effect that was not an implemented feature
>> of the raytracing package you are using. The intent of the rule is to
>> cause you to use your skills and imagination to get the effects you
>> need using the software provided and features of what that software
>> provides. Many raytracing effects can be simulated in 2D paint packages
>> but are not what the irtc is all about.
>>
>> These are my opinions and yours may very.
>>
>> Ken Tyler
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 7 Dec 1998 22:32:28 -0800, Chris Jeppesen <chr### [at] digiquill com> wrote:
>Can't you model it directly as an object? I am working on a still that has
>motion blur, and
>it is done by using multiple transparent copies of an object. Sure it takes
>longer to render,
>but it is completeley POV (no patches even) and doesn't require any extra
>software
Technically, though, it isn't completely accurate. Consider a cube that has
been "blurred" in this way. Now consider a point that is occupied by the
cube for the entire exposure. Its color should be exactly that of the cube,
but using the "multiple transparent objects" method it won't be, because no
matter how many cubes you use, you'll still have some transparency. You
can make that part accurate by using enough cubes that the remaining
transparency is less than 1/255, but the rest of the trail is inaccurate as
well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <365c813a.0@news.povray.org>,
"Mick Hazelgrove" <mic### [at] virginnet> writes:
> I've been told that any process that affects the whole pic is acceptable
> i.e sharpening, auto equalization etc.
Sorry, Nick, you've been slightly misled. The "affects all pixels" comment
isn't a rule, it's just a guideline. And the key point is its suggestion that
processes which affect all pixels *equally* (like lightening or darkening) are
within the spirit of the rule, while things which affect some pixels one way
and others a different way (like sharpening, lens flare, color adjustment,
etc.) are certainly not.
The rule really is *no* post-processing, with three stated exceptions. We
would actually prefer *no* exceptions, but until all renderers can output JPEG
format directly, and have built-in gamma correction, that's not possible. As
others have noted here, the thing we want to emphasize is how good you are
with a *renderer*, not with a paint program.
Lots of people like pushing rules as close to the edge as possible, apparently
because they think it gives them some sort of advantage. As the judges have
shown, talent and skill win every time; rules-lawyers are really only hurting
themselves.
--
Chip
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
