![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
So what's the big deal of actually modifying POV-Ray with a new AA method?
AA shoots multiple rays for a single pixel which is then averaged. How is
that different than just taking a higher rendering of the image and
averaging the pixels? Why is it such a big deal to modify the renderer?
Megapov does post processing and I don't see such huge debates about that...
"Warp" <war### [at] tag povray org> wrote in message
news:3ca8ed48@news.povray.org...
> Kari Kivisalo <pro### [at] luxlab com> wrote:
> >> I think that's really bending the rules.
>
> > Resizing is allowed.
>
> My statement still holds.
>
> I don't think that the people who decided about that rule thought that
> it could be used to enhance the quality of the image.
> It's the spirit of the IRTC rules that the quality of the image produced
> by the renderer should not be enhanced by post-processing. The image
should
> be the one produced by the renderer, with no modified quality. If the
> image produced by the renderer had artifacts, it's against the rules to
> remove these artifacts with a paint program. Using the resizing trick
> is essentially doing this.
> We should think about the rules in their whole context and understand
> the spirit of the rules, not just their letter.
>
> --
> #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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 1 Apr 2002 15:08:40 -0500, Warp <war### [at] tag povray org> wrote:
> > It is much better than my method, which I used in my two last IRTC entries.
> > I will no more use normal POV-Ray antialiasing, as such methods show enhance
> > most pictures considerably.
>
> I don't think you can do that with an IRTC entry. The rules prohibit
> post-processing.
What about writing the same as function in 3.5 ?
ABX
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Becker <cmb### [at] rit edu> wrote:
> So what's the big deal of actually modifying POV-Ray with a new AA method?
Nothing.
> AA shoots multiple rays for a single pixel which is then averaged. How is
> that different than just taking a higher rendering of the image and
> averaging the pixels?
It's different because the latter method is post-processing. It's not
something the renderer itself supports, but has to be done with a paint
program.
> Why is it such a big deal to modify the renderer?
It isn't.
> Megapov does post processing and I don't see such huge debates about that...
Because it's the renderer itself which does it.
The idea is to participate with the output image of a renderer, not a
rendered image which has been enhanced with another program afterwards.
The IRTC rules prohibit post-processing for this reason.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> What about writing the same as function in 3.5 ?
How?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 2 Apr 2002 08:15:25 -0500, Warp <war### [at] tag povray org> wrote:
> W?odzimierz ABX Skiba <abx### [at] babilon org> wrote:
> > What about writing the same as function in 3.5 ?
>
> How?
Knowing algorithm for particular effect in 2d manipulation software writing
macro/pattern applied to plane with ambient 1 and diffuse 0 under orthogonal
camera. Then it use all elements of typical still creation process but has the
same effect. OF course it is cheating but probably works.
ABX
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Knowing algorithm for particular effect in 2d manipulation software writing
> macro/pattern applied to plane with ambient 1 and diffuse 0 under orthogonal
> camera. Then it use all elements of typical still creation process but has the
> same effect. OF course it is cheating but probably works.
Well, I could just take a photograph, put it as pigment to a plane and
render that plane.
Technically the resulting image has been produced by the renderer and is
perfectly legal according to the rules.
However, somehow I doubt that I would win that way. ;)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Kari Kivisalo <pro### [at] luxlab com> wrote:
>>
>>Resizing is allowed.
>>
>
> My statement still holds.
>
Hmmm... I think the problem is not "resizing". Altough today paint
programs can resize much better, only resizing doesn't gives so good
results, at least not much better than +a0.0. The "artifact" or "moire"
removing step is done with the previous gaussian filter, and *this is*
postprocesing, not the resizing. IMHO, resizing only must be still
allowed, but perhaps has not much sense today, as there are no
resolution limits for the image (I think this rule was created to allow
people to fit the maximum resolution allowed at that time).
--
Jaime Vives Piqueres
http://www.ignorancia.org/
La Persistencia de la Ignorancia
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jaime Vives <jai### [at] ignorancia org> wrote:
> Hmmm... I think the problem is not "resizing". Altough today paint
> programs can resize much better, only resizing doesn't gives so good
> results, at least not much better than +a0.0. The "artifact" or "moire"
> removing step is done with the previous gaussian filter, and *this is*
> postprocesing, not the resizing. IMHO, resizing only must be still
> allowed, but perhaps has not much sense today, as there are no
> resolution limits for the image (I think this rule was created to allow
> people to fit the maximum resolution allowed at that time).
The problem with resizing an image smaller is that there are basically two
ways of doing it (from the point of view of the program):
1. Make the image smaller by just dropping out pixel rows and columns
appropriately.
2. Make the image smaller by calculating (weighted) averages of pixel
rows and columns.
The problem with method 1 is aliasing.
The problem with method 2 is that it's in practice filtering the image,
which can enhance its visual quality and is thus post-processing.
There wouldn't be a problem with method 2 if post-processing was not against
the spirit of the competition. IMO it's such a big filtering process that it
does not fit inside the rules.
--
#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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> wrote in message news:3ca9aecd@news.povray.org...
<snip>
From what I understand of this debate, does this resize-for-better-aa really
break the rules, either in spirit or fact?
I take your point that to resize to get rid of artifacts is a definate no-no,
but the aa issue seems linked to the size of the image-output, rather than an
inherant problem with the scene.
In other words if the defect corrected by resizing is present in the high
resolution image, then you are breaking the rules. However, if the defect is not
present at high res., and you are merely trying to duplicate the "clean" image
at a lower-res. then I don't think any rules, spirit or fact, have been broken.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Tom Melly" <tom### [at] tomandlu co uk> wrote in message
news:3ca9cd6f@news.povray.org...
<snip>
As a personal note, IMHO I've never really understood the IRTC leniency towards
post-process adjustment of brightness/contrast/etc.
I do it, but it seems a damn sight more dishonest than a resize for aa purposes
(never done that as I've never needed to).
Suggest this moves to irtc.general ?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |