 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406d8791@news.povray.org>, Warp <war### [at] tag povrayorg>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406ecc03@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> At least I would disallow using an external image manipulation program
> which is unrelated and separate from the renderer.
What's the difference between doing some operation using an external
program that's unrelated to the renderer and using an external program
that's packaged along with the renderer? The resulting image and the
algorithms used to generate it may be exactly the same.
> 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.
Right. You could process the image in these ways with POV-Ray, as well.
Would the image be disqualified in that case?
> 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.
Isn't it? At what point does it cease to be "rendered"? What is the
difference between a raytracer applying a contrast filter pixel by pixel
as the image is traced, and doing the same operation in an external
program?
The IRTC is the Internet Ray Tracing Competition, not the Internet Ray
Tracer Competition. I'd say it is the skill of the artist at producing
images with raytracing which matters. A contrast adjustment on a blank
image won't do anything, the artist has to make an image worth viewing
first.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > At least I would disallow using an external image manipulation program
> > which is unrelated and separate from the renderer.
> What's the difference between doing some operation using an external
> program that's unrelated to the renderer and using an external program
> that's packaged along with the renderer? The resulting image and the
> algorithms used to generate it may be exactly the same.
The difference is whether the image was produced by the renderer
called XYZ or not. It shows "the renderer XYZ can produce images
like this".
If you post-process the result of the rendering with an external
program (ie. *you* use the external program, not the renderer) the
result will be something the renderer is not able to produce.
And besides, if you want to allow any post-processing with any
unrelated image manipulation program, why do you want to restrict
it to only things that can be made "automatically" by the program
and not things the user can draw by hand? Why this kind of artificial
limitation? And where do you draw the line between something made
"automatically" by the program and something made "by hand" by the
user?
> > 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.
> Right. You could process the image in these ways with POV-Ray, as well.
> Would the image be disqualified in that case?
It's something you get directly from the renderer. Why it should be
forbidden? It's not using photoshop or gimp to achieve something the
program cannot produce.
That's the difference: Can this renderer *directly* produce this
image, or do you need a third-party program for that?
> > 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.
> Isn't it?
Nope. Just part of the image information is what the renderer produced.
If you render a small logo and then use it in a hand-drawn image,
can you call the image, the whole image, "rendered"? No, only part
of the image has been rendered.
> At what point does it cease to be "rendered"?
At the point when the result of the rendering is modified.
How much modifications, in your opinion, can be made to a rendered
image so that it can still be considered "rendered"?
If you, for example, shuffle the location of all the pixels randomly,
is it still a "rendered" image? The result is just random noise. It may
be pseudo-random because it's based on existing data (the rendered
image), but it's still just noise, not a rendered image.
> What is the
> difference between a raytracer applying a contrast filter pixel by pixel
> as the image is traced, and doing the same operation in an external
> program?
The difference is whether it's the renderer which is able to produce
the resulting image or not.
> The IRTC is the Internet Ray Tracing Competition, not the Internet Ray
> Tracer Competition. I'd say it is the skill of the artist at producing
> images with raytracing which matters. A contrast adjustment on a blank
> image won't do anything, the artist has to make an image worth viewing
> first.
But considerably increasing the visual quality of an image by using
an image manipulation program is, in my opinion, against the spirit
of the competition.
Even a bad image can be greatly enhanced with all kinds of effects
supported by photoshop. Are we competing on who can use photoshop's
filters best?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
First, it goes without saying that not everyone will be interested
in every competition....for example, I rarely enter the IRTC.
However in defence of this particular contest, there can indeed
be a significant challenge in representing many fractal forms. The
challenge normally comes in the form of the memory required for
the geometric data needed to represent fractals that in their
"pure" mathematical form have infinite detail.
For example, consider some of the clever methods that were discussed
a few weeks ago in this group on how to render the attractor I
entered into the SCC3
http://astronomy.swin.edu.au/~pbourke/fractals/peterdejong/
I certainly found it difficult to create the sphere positins for
the Apollonian fractal
http://astronomy.swin.edu.au/~pbourke/fractals/apollony/
The last images on that page have over 3 million spheres.
I would suggest that another challenge in this competition will
be to find something new. Everyone has seen quaternions and they
can certainly be made sexy, perhaps though a "new" fractal will
catch peoples eye more. (?). ps: I don't mean to discourage those
who are working on sexy quaternions.
--
Paul Bourke
pdb_NOSPAMswin.edu.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406ee7ca@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> The difference is whether the image was produced by the renderer
> called XYZ or not. It shows "the renderer XYZ can produce images
> like this".
I don't care if it's done by working the math out with paper and pencil.
> If you post-process the result of the rendering with an external
> program (ie. *you* use the external program, not the renderer) the
> result will be something the renderer is not able to produce.
And so? The algorithms that generate the image can be equivalent to
those used to generate the image with a single program. What's the
difference? Again, this is not a competition between rendering packages.
> And besides, if you want to allow any post-processing with any
> unrelated image manipulation program, why do you want to restrict
> it to only things that can be made "automatically" by the program
> and not things the user can draw by hand? Why this kind of artificial
> limitation? And where do you draw the line between something made
> "automatically" by the program and something made "by hand" by the
> user?
Because a procedure done by hand can not be reproduced. An algorithmic
procedure can be.
> It's something you get directly from the renderer. Why it should be
> forbidden? It's not using photoshop or gimp to achieve something the
> program cannot produce.
>
> That's the difference: Can this renderer *directly* produce this
> image, or do you need a third-party program for that?
It's the same process. What does it matter how it was produced?
I will not accept that a gaussian blur is "rendering" if it is done by
the program that generated the original image, but not if it is done by
a separate program. The result is the same. It looks the same, and was
generated the same way.
> If you render a small logo and then use it in a hand-drawn image,
> can you call the image, the whole image, "rendered"? No, only part
> of the image has been rendered.
Of course. Most of the image would be hand drawn. I've said several
times that hand modification should not be allowed, do you think I'd
accept a hand drawing?
> At the point when the result of the rendering is modified.
What's the result of the rendering? The color seen along each ray? The
gamma correction done by POV-Ray modifies that...no image using gamma
correction is a legal IRTC image?
> How much modifications, in your opinion, can be made to a rendered
> image so that it can still be considered "rendered"?
I already answered that. Drawing, painting, and other "by hand"
manipulation is out. Anything accepted as part of the rendering package
should also be accepted if done by a program outside the rendering
package. If a MegaPOV post-process convolution blur is acceptable, than
any other convolution blur should be acceptable.
Otherwise, limit entries based on the actual algorithms used. Color
adjustment should be allowed: gamma correction, contrast, etc. Resizing.
A small overlay for a signature, which should not affect the overall
image. Judging this would require in-depth knowledge of how the software
that generated the image works.
> If you, for example, shuffle the location of all the pixels randomly,
> is it still a "rendered" image? The result is just random noise. It may
> be pseudo-random because it's based on existing data (the rendered
> image), but it's still just noise, not a rendered image.
I can do the exact same thing with just POV-Ray. Does that magically
make it "rendered"?
To answer your question, yes, I'd still call it a rendered image. It
just wouldn't be an image of anything, and would be off-topic for pretty
much any IRTC competition.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You are speaking of a competition quite different from IRTC.
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Again, this is not a competition between rendering packages.
From the rules:
"Any rendering program is acceptable."
"Images must not be enhanced or altered ('post-processed') by use of
paint programs such as PhotoShop(tm) etc."
"Examples of unacceptable post-processing would be adding lens-glare,
tinting skies, or using filters such as motion blur."
If this is not a competition between rendering packages, then what is?
> I've said several
> times that hand modification should not be allowed, do you think I'd
> accept a hand drawing?
[...]
> Otherwise, limit entries based on the actual algorithms used.
"Paint programs may be used for the creation of image maps and the like,
but may not be used to alter the rendered image."
Your principle would mean that you can't use a painting program to
make textures by hand.
What you are saying is that you must make the image completely
algorithmically and that hand-drawing is not acceptable. This is
not the IRTC. This is something different.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Harold <bai### [at] 3dculturecom> wrote:
>
>>Then don't participate.
>
> I might not, because I'm not artistically very talented, and I really
> lack any good ideas for this topic.
Funny: I'm the same way, yet I'm thrilled this is here because us
techies can come out to play :-)
--
Respectfully,
Dan P
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
