 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is the minimum scene-file Thorsten Froehlich requested to
check the bug. When tracing with focal-blur, objects get
cut in half or vanish, depending on which object you use
to be translated by vnormalize(<0,0,0>).
Interesting side-effect:
The "cut" is "blurred focally", or at least it appears so.
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmx de
Post a reply to this message
Attachments:
Download 'us-ascii' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> This is the minimum scene-file Thorsten Froehlich requested to
> check the bug. When tracing with focal-blur, objects get
> cut in half or vanish, depending on which object you use
> to be translated by vnormalize(<0,0,0>).
Oh... well, if you use vstr() with vnormalize(<0,0,0>), you will se it
returns a vector <nan,nan,nan>. If you look also at the docs, the
description for vnormalize() "criptically" states that "vnormalize(<0,0,0>)
will not give a usefull result". This sounds more like an undesired side
effect than a bug... and from the docs wording I can supose there is no
easy solution for the problem. Note this sentence was not on the 3.1 docs,
so I suspect it was discussed on a previous bug report...
Anyhow, if your using vnormalize inside loops, you can test for the
"special case" to replace it with the apropiate value (if it makes sense at
all).
Hope this helps!
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Oh... well, if you use vstr() with vnormalize(<0,0,0>), you will se it
> returns a vector <nan,nan,nan>. If you look also at the docs, the
> description for vnormalize() "criptically" states that "vnormalize(<0,0,0>)
> will not give a usefull result". This sounds more like an undesired side
> effect than a bug... and from the docs wording I can supose there is no
> easy solution for the problem. Note this sentence was not on the 3.1 docs,
> so I suspect it was discussed on a previous bug report...
This is a case where there's no simple solution, even though it could
look like that at first glance.
Some people think that vnormalize(<0,0,0>) should return <0,0,0>.
That's *not* a good solution because it breaks the very definition of
vnormalize. vnormalize is defined to always return a vector of lenght 1,
which <0,0,0> is not. If you trust that it always returns a vector of
that length but there's a special case where it doesn't, then you can't
trust it anymore.
The best solution is, of course, that POV-Ray would issue an error if
a 0-vector is normalized (because it can't). Getting a clear error message
is always better than getting a weird result.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The best solution is, of course, that POV-Ray would issue an error if
> a 0-vector is normalized (because it can't). Getting a clear error message
> is always better than getting a weird result.
I most definitely agree.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
