[fixed]Documentation Fixes

[REDDemon]

1) SViewFrustum.

Documentation mistyping at line 22.

Frustum view has 8 points not 4.


2) SViewFrustum

Documentation missing line 129.

ClassifyPoint relations need a normalized normal. This is not told in the documentation.

demonstration:

assume the ZY PLane (the normal to that plane is the X vector)
so
Normal(1,0,0)
and
D = 0;

take the point (3,0,0)

if the Normal is not normalized so assume (2,0,0)
Then distance from the point will return 6 instead of 3.



3)
file "matrix4.h"

line 1064

Transforming a vector like this way requires an affine matrix. This is not
told in documentation. So the method theorically won't work correctly with perspective matrices

[hybrid]

Not sure what you mean about the matrix problem. The transform is correct for a 3-component vector. We assume a '1' in the fourth component. If you need a full 4x4 transform use the additional 4-component output transform. The rest is fixed.
BTW: I didn't change just the classifyPointRelation comment, but added a general hint to the class. Because also other methods rely on a normalized normal. And your example didn't give wrong results, IMHO, but a different D point would.

[REDDemon]

And your example didn't give wrong results, IMHO, but a different D point would.

D that was not the point

D is just the fourth member of the plane equation. My example shows that using as normal (1,0,0) the result is 3. Using as normal(2,0,0) (of course if you can call it "normal" XD) the result becomes 6.. assumed that the plane is the same (always YZ) there's no reason for wich the function should return different distances for the same point (3,0,0).

Just signaled functions wich have failed unit testing. (i'm not testing the whole engine, but just functions wich I use ).

For the matrix just forget that irrlicht uses LH coord system. so the column wich I expect to be used is left as (0,0,0,1) while the line wich remains untouched in opengl (the 4th) is used by irrlicht

[hybrid]

Maybe you mean a different method in plane3d then. classifyPointRelation just returns an enum value, which says in front, back, or planar. The inner calculation of the dot product would be wrong, though. And this could lead, with a different D value, to a wrong classification. At least that's what I saw in the code. Didn't do any test cases, yet. Anyway, a plane with a non-normalized normal will fail in many cases. So it's best to avoid it.