POV-Ray : Newsgroups : povray.beta-test : Vanish/Ghost/Killer bug : Re: Vanish/Ghost/Killer bug Server Time
29 Jul 2024 16:33:29 EDT (-0400)
  Re: Vanish/Ghost/Killer bug  
From: Tim Nikias
Date: 16 Apr 2002 13:38:32
Message: <3CBC61A0.9217A1ED@gmx.de>
How about returning <0,0,0> as value AND giving
a warning-message? As long as that vector is needed
for translation, an error might be fine, but in certain
cases, in certain POV-SDL-Code, you might do
thousands of calculations with vnormalize(), but only
one (due to some random input) may result with
vnormalize(<0,0,0>).
So, at least programming would be made easy.

Of course, the solution would be a macro, purposefully
named
VNormalize ( Vector ), which checks the length of the
vector (using vlength()), and if its !=0, you normalize,
otherwise, return a preffered value e.g. <0,0,0> or <0,1,0>.

That's what I'll probably do, because I believe this
bug is similiar to that strange pow() behaviour, and it may
be impossible and very inefficient to check for the
vnormalize(<0,0,0>) in POV itself (I think there a lot
of things which are done by POV because of inefficiency).

And regarding "reducing" the scene:
How about putting a section in the Docs which simply
state a list of "probably unexpected behaviour", which
cover pow(), vnormalize(), and I don't know what else
pops up? Just than one can check easily and fast.

ingo wrote something like:

> I would prefer an error. While making mesh generation macros I've been
> bitten by this often. Investigation always showed that I did something
> wrong in my code with the result of a <0,0,0> vector. It always took a
> while to find the problems because POV-Ray just goes on parsing after a
> vnormalize(<0,0,0>).
>

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.