 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey all,
I'm working on a scene where I have a problem with some horizontal lines,
and yes, the problem is antialiasing. The thing is, I've tried +a0.0 +am2
and there's really not a lot of difference in this particular part of the
scene, still jaggies even though the scene as a whole does look better.
Anyway, these horizontal lines are really probably about 15 - 20 degrees
to the horizontal in the actual image - hence the jaggies.
Now to the point. ;) I did a few experiments* where I used +a0.0 +am1
and the same but with +am3, and there was a significant difference in speed:
o- +a0.0 +am1 = 35 secs
o- " +am2 = 2:30 secs
o- " +am3 = 36 secs
o- +a0.0 --- = 39 secs
* These experiments included a small selection in the winPoV render
window - I used the exact select dimensions for each render used in this
mini-experiment.
Does PoV-Ray not recognise +am1, +am3?
The scene still rendered with +am1, +am3, but what did it really
render? Also, +a0.0 on its own took longer(!) I thought when I tried it, it
would be quicker than +am1 or +am3.
Second from last question, (silly question too): what does the 'am'
stand for?
Lastly, how can I improve these jaggies?
~Steve~
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dot com> wrote:
> Now to the point. ;) I did a few experiments* where I used +a0.0 +am1
> and the same but with +am3, and there was a significant difference in speed:
There's no method 3. I guess povray is reverting to method 1.
> Second from last question, (silly question too): what does the 'am'
> stand for?
Antialiasing method.
> Lastly, how can I improve these jaggies?
If rendering time is not an issue, you can increase the number of
samples using the +r option. The default is +r3 (which means 3x3 rays).
Try with +r4 or +r5 (and expect heavy slowdown of the rendering).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:46c7416d@news.povray.org...
> St. <dot### [at] dotcom> wrote:
>> Now to the point. ;) I did a few experiments* where I used +a0.0 +am1
>> and the same but with +am3, and there was a significant difference in
>> speed:
>
> There's no method 3. I guess povray is reverting to method 1.
So, method 1 is recognised by PoV-Ray but not method 3. It still
leaves the question of what method 1 is good for compared to +a0.0?
>
>> Second from last question, (silly question too): what does the 'am'
>> stand for?
>
> Antialiasing method.
Dang... :o/
>
>> Lastly, how can I improve these jaggies?
>
> If rendering time is not an issue, you can increase the number of
> samples using the +r option. The default is +r3 (which means 3x3 rays).
> Try with +r4 or +r5 (and expect heavy slowdown of the rendering).
Phew! Well, this is an image that I have to go through with. But,
you've taught me something new there Warp. Thanks.
I'll give that a try and hope it comes good. ;)
~Steve~
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dotcom> wrote:
> So, method 1 is recognised by PoV-Ray but not method 3.
Methods 1 and 2 are two different sampling algorithms. There's no
method 3.
> It still
> leaves the question of what method 1 is good for compared to +a0.0?
There's nothing to compare. The +a and the +am options are two different
parameters of antialiasing (the fact that both start with "+a" is a mere
question of syntax). The option +a turns on antialiasing calculations, and
it can take a threshold value as parameter. The +am option specifies the
algorithm to use for antialiasing (1 being the default when this option
is not given).
The threshold given to +a means how much adjacent pixels must differ
before antialiasing samples are taken. The antialiasing method simply
tells how those samples are taken. They are basically different and
independent settings.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
St. wrote:
> Hey all,
>
> I'm working on a scene where I have a problem with some horizontal lines,
> and yes, the problem is antialiasing. The thing is, I've tried +a0.0 +am2
> and there's really not a lot of difference in this particular part of the
> scene, still jaggies even though the scene as a whole does look better.
>
> Anyway, these horizontal lines are really probably about 15 - 20 degrees
> to the horizontal in the actual image - hence the jaggies.
>
> Now to the point. ;) I did a few experiments* where I used +a0.0 +am1
> and the same but with +am3, and there was a significant difference in speed:
>
> o- +a0.0 +am1 = 35 secs
> o- " +am2 = 2:30 secs
> o- " +am3 = 36 secs
> o- +a0.0 --- = 39 secs
>
In addition to what Warp already said:
- +am1 is the default, therefore "+a0.0 +am1" and "+a0.0" are
identical;
- with the default recursion depth of 3, method 1 will use 9
samples per pixels, whereas method 2 will use 81 samples per pixel.
This explains the timing differences you see.
To improve the jaggies, I would suggest rendering at a higher
resolution (say multiplying the image dimensions by 2), then
downscaling the image. At the same time, you should raise the AA
threshold to 0.1 or 0.2 in order to improve the rendering speed.
Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGya0hd0kWM4JG3k8RAiX6AJ9J9uOOorbyzvI31mz2X681Svw57QCghvUE
Q0fw9dUSbT8/fF/0jV2NMQI=
=3KTv
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <jeb### [at] freefr> wrote:
> whereas method 2 will use 81 samples per pixel.
A *maximum* of 81 samples per pixel.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Warp wrote:
> "J�r�me M. Berger" <jeb### [at] freefr> wrote:
>> whereas method 2 will use 81 samples per pixel.
>
> A *maximum* of 81 samples per pixel.
>
With +a0.0, the maximum is always reached isn't it?
Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGygxYd0kWM4JG3k8RAglxAJ4jIlon67af+oW5CRFM55bLVtofCgCgvNzM
Ia6B4HLtIqOlbmlfK0hlOJI=
=5qxz
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. escribió:
> So, method 1 is recognised by PoV-Ray but not method 3. It still
> leaves the question of what method 1 is good for compared to +a0.0?
>
+a0.0 is useless. It will supersample even if there is a completely
color. Even +a0.001 could be useful in some cases, but +a0.0 is simply a
waste of CPU time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> It will supersample even if there is a completely color.
OK that got messed up... I meant "It will supersample even if there is a
completely plain color." Even if your whole image is the exact same
color, +a0.0 will supersample it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Nicolas Alvarez who wrote:
>Nicolas Alvarez wrote:
>> It will supersample even if there is a completely color.
>
>OK that got messed up... I meant "It will supersample even if there is a
>completely plain color." Even if your whole image is the exact same
>color, +a0.0 will supersample it...
It is sometimes useful to supersample images for which the colour is
exactly the same at integer pixel positions, but which have sub-pixel
features.
For example:
camera {location <0,0,-10> look_at 0}
plane {z,0
pigment {gradient x
colour_map {[0.005 rgb 0][0.005 rgb 1]}
}
finish {ambient 1}
}
If you render that with any non-zero antialias threshold then it will
miss some of the lines where the line happens to squeeze between pixels.
How many lines are missed depends on the image size: at 320x240 all the
lines are missed.
If you render it with +a0.0 then it finds all the lines.
That's a bit of an extreme example, but it's possible to encounter the
same sort of effect in real scenes.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Williams wrote:
> Wasn't it Nicolas Alvarez who wrote:
>> Nicolas Alvarez wrote:
>>> It will supersample even if there is a completely color.
>> OK that got messed up... I meant "It will supersample even if there is a
>> completely plain color." Even if your whole image is the exact same
>> color, +a0.0 will supersample it...
>
> It is sometimes useful to supersample images for which the colour is
> exactly the same at integer pixel positions, but which have sub-pixel
> features.
>
> For example:
>
> camera {location <0,0,-10> look_at 0}
>
> plane {z,0
> pigment {gradient x
> colour_map {[0.005 rgb 0][0.005 rgb 1]}
> }
> finish {ambient 1}
> }
>
> If you render that with any non-zero antialias threshold then it will
> miss some of the lines where the line happens to squeeze between pixels.
> How many lines are missed depends on the image size: at 320x240 all the
> lines are missed.
>
> If you render it with +a0.0 then it finds all the lines.
>
> That's a bit of an extreme example, but it's possible to encounter the
> same sort of effect in real scenes.
>
In that case, render at a higher resolution with +a0.1, then
downscale the image with an external tool. This will be faster than
+a0.0 for an equivalent quality.
Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGyxoId0kWM4JG3k8RAjczAJ91+3ApROl9yf0S3O8Hxx/Ng89fGwCfcV8x
ePvr5YKDAmvurTcn772pIcc=
=y667
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Jérôme M. Berger who wrote:
>Hash: SHA1
>
>Mike Williams wrote:
>> Wasn't it Nicolas Alvarez who wrote:
>>> Nicolas Alvarez wrote:
>>>> It will supersample even if there is a completely color.
>>> OK that got messed up... I meant "It will supersample even if there is a
>>> completely plain color." Even if your whole image is the exact same
>>> color, +a0.0 will supersample it...
>>
>> It is sometimes useful to supersample images for which the colour is
>> exactly the same at integer pixel positions, but which have sub-pixel
>> features.
>>
>> For example:
>>
>> camera {location <0,0,-10> look_at 0}
>>
>> plane {z,0
>> pigment {gradient x
>> colour_map {[0.005 rgb 0][0.005 rgb 1]}
>> }
>> finish {ambient 1}
>> }
>>
>> If you render that with any non-zero antialias threshold then it will
>> miss some of the lines where the line happens to squeeze between pixels.
>> How many lines are missed depends on the image size: at 320x240 all the
>> lines are missed.
>>
>> If you render it with +a0.0 then it finds all the lines.
>>
>> That's a bit of an extreme example, but it's possible to encounter the
>> same sort of effect in real scenes.
>>
> In that case, render at a higher resolution with +a0.1, then
>downscale the image with an external tool. This will be faster than
>+a0.0 for an equivalent quality.
Depends how large you want the final image. If you want a 640*480 image
of the above example, then it's faster to use +a0.0 at 640*480. On my
machine it takes 4.8s to render at 640*480 +a0.0, but in order to see
all the lines at +a0.1 it needs to be scaled up to about 2300*1725 which
takes 9.4s.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Williams wrote:
> Wasn't it Jérôme M. Berger who wrote:
>> Hash: SHA1
>>
>> Mike Williams wrote:
>>> Wasn't it Nicolas Alvarez who wrote:
>>>> Nicolas Alvarez wrote:
>>>>> It will supersample even if there is a completely color.
>>>> OK that got messed up... I meant "It will supersample even if there is a
>>>> completely plain color." Even if your whole image is the exact same
>>>> color, +a0.0 will supersample it...
>>> It is sometimes useful to supersample images for which the colour is
>>> exactly the same at integer pixel positions, but which have sub-pixel
>>> features.
>>>
>>> For example:
>>>
>>> camera {location <0,0,-10> look_at 0}
>>>
>>> plane {z,0
>>> pigment {gradient x
>>> colour_map {[0.005 rgb 0][0.005 rgb 1]}
>>> }
>>> finish {ambient 1}
>>> }
>>>
>>> If you render that with any non-zero antialias threshold then it will
>>> miss some of the lines where the line happens to squeeze between pixels.
>>> How many lines are missed depends on the image size: at 320x240 all the
>>> lines are missed.
>>>
>>> If you render it with +a0.0 then it finds all the lines.
>>>
>>> That's a bit of an extreme example, but it's possible to encounter the
>>> same sort of effect in real scenes.
>>>
>> In that case, render at a higher resolution with +a0.1, then
>> downscale the image with an external tool. This will be faster than
>> +a0.0 for an equivalent quality.
>
> Depends how large you want the final image. If you want a 640*480 image
> of the above example, then it's faster to use +a0.0 at 640*480. On my
> machine it takes 4.8s to render at 640*480 +a0.0, but in order to see
> all the lines at +a0.1 it needs to be scaled up to about 2300*1725 which
> takes 9.4s.
>
Here, it takes 26s at 640x480 with +a0.0 and 15s at 3200x2400 with
+a0.1 +r1 (which gives the same potential resolution). The result is
actually better in the second image.
Result images are here:
http://jeberger.free.fr/public/povray/
Jerome
PS: This is all done with method 2 of course. When using method 1,
the render is faster (4s), but the result is much worse:
http://jeberger.free.fr/public/povray/aa-640x480x1-0.0-m1.png
PS2: I also tried it at 1920x1440 with +a0.1 +r2. It renders in 6s,
but some lines are imperfect. All in all, I'd consider its quality
on a par with the method 1 result (some lines are worse, some are
better).
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGzIRcd0kWM4JG3k8RAoljAJ9W7N4c9DmcC+n22iq2Bkf1JSJy9QCggNVI
16UeS/ubR/mpVXhdvG9IW78=
=lGva
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"St." <dot### [at] dotcom> wrote in message news:46c73dde$1@news.povray.org...
Well, hey, thanks all, what you've all said has made interesting reading.
I think I'm going to go down the double resolution route and resize down.
The problem with this though, is that until you've done this yourself for
experience, you would never know how the final image would turn out, and
especially (for me), in the region of normals.
Thoughts?
~Steve~
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"St." <dot### [at] dotcom> wrote:
> Thoughts?
>
> ~Steve~
Steve,
Not an aa solution but I had a similar problem a couple of years ago and the
only way that I could resolve it was to use an orthographic camera. It does
make the scene look different but it may work for your scene.
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
