This may sound very stupid but how do you write a floating point library for vectors and such if there are going to be very small rounding errors Say for addition of two vectors V1 and V2, normally result.x = V1.x + V2.x and same for y and z Should I first test if V1 or V2 equals to the zero vector (within some tolerance) and then sets them to zero before the addition, like so if V1 equals 0 // within some tolerance set V1 to 0 if V2 equals 0 set V2 to 0 result = V1 add V2 If I don''t, say V1 and V2 are very close to zero, won''t there be a chance that the error will accumlated until the result is no longer 0 and say, you take the result for a multiplication next(and all hell will break loose) ..

Whats the purpose of your lib? If you want to write a vector/matrix class for games (hell, this is what we are here for :-) than such a simple operation as the addition of two vectors shouldn''t incooperate if-tests! An if-test can stall the cpu-pipeline. Nobody would expect such a test in a addition or other vector operations.

The lib is so low level that you should write something like:

#include
#include

#ifndef FLT_EPSILON
# define FLT_EPSILON 1.192092896e-07F
#endif // FLT_EPSILON

class Vector3
{
public:
float x,y,z;
...

// tests absolute equality
bool operator=(const Vector3& vec_) const {return x==vec_.x && y== vec_.y && z==vec_z;};

// test of equality with tolerance
bool equalWithTolerance(const Vector3& vec_ , float tolerance=FLT_EPSILON) const { return (fabsf(x-vec_.x)
// perhaps it is better to use (y-vec_.y)
// set to zero
void makeZero() {x=0.0f; y=0.0f; z=0.0f;} {x=0.0f; y=0.0f; z=0.0f;};

...

};

This way the user (or you ion higher tiers of your lib) is able to choose exactly the behavieour he wishes.

Ah, and remember, incremental methods which will need numerous additions of vectors should be "normalized" after some steps to kill rounding-errors and effects.

What do you think - suggest?

Uh, what a beast of a reply...

Bjoern

The vector library is to be combined with a quaternion library for a inverse kinematics link chain system.

The algorithm I use is iterative, about 100 times per frame, many times per second.

So what you are saying is to handle the error in the algorithm, not the libraries??

Hm, I don''t get your last comment. We have a name clash (lib, algo,...) here :-)

What I suggest is:

- don''t clean up rounding errors and small deltas in simple math functions like add, subtract, multiply, divide, ...
- provide functions to get rid of deltas and rounding errors
- Use this "clean-up-funcs" in higher levels of your app (for example in the function which iterates about your data) WHEN it is needed. By inlineing these functions you won''t get a performace penalty in comparison to add the "claen-up" code into your math functions.

Are you using the iteratively calculated data in the next frame also or are you recalculating it (freshly :-) in every frame? You should test if the accumulated errors in one frame are worth the clean-up. My guess is, that you would only need to clean up your data ones every frame (if you use the iteratively calculated data in the next frame also).



Bjoern

P.S.: Do you have good sources about inverse cinematics? Would you mind posting a link then? Thanks!

Well, the only link I have (and can find) about the CCD algorithm for IK is

http://www.darwin3d.com/gamasutr.htm

But note that the maths library does not take into account clamping and such.

I don''t think cleaning up per frame is good enough cause the algorithm runs 100 times per frame. (And I not sure where to place those checks, except in all the places

Opps wrong link

http://www.darwin3d.com/gdm1998.htm

Thx for the link!

Do you already have results from your algorithm? Perhaps you could calculate the additions with and without checks and compare the results to see if the error is bad enough to attack it as rigorously as you suspect it to be necessary.

I will take a look into the IK infos of your link (big question: how long will I need). Perhaps I will get a better grasp of the error accumulation problem then.


Bjoern
(I should register myself to get rid of the "anonymous" - this looks a little bit unserious...)

It sort of works in 3D.. but at certain angles, it can''t get to the position it should.

I am currently writing a vector and quaternion library, b4 rewriting everything. will post it up when I''m done.

Even for a simple function like the dot product which should return -1 to 1, sometimes it returns 1.0000001, which will screw things big time.

Yes.Plz do register yrself.