 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] free fr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>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:
>> 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
|
|
| |
| |
|
|
|
|
| |
