Vertex3f curiosity

I was going through the Vertex3f.java source file, and I saw this (line 611):

public Vector3f divideLocal(float scalar) {
        scalar = 1f/scalar;
        x *= scalar;
        y *= scalar;
        z *= scalar;
        return this;
    }

Why are the single component multiplied by the reciprocal of scalar? I think a proper implementation would be

public Vector3f divideLocal(float scalar) {
        x /= scalar;
        y /= scalar;
        z /= scalar;
        return this;
    }

Am I missing something?

it costs 2 more divisions. divisions are more CPU consumming than multiplications

1 Like

Ah, you are right.

Tho i guess that the jit could optimize this itself, but then it needs time for that, and especially in a math heavy library this can make sense.

The FastMath library really is optimised to hell and back, isnt it?

It is indeed a remarkable piece of software engineering.

It kinda is, you never know what will be done with so generic math stuff, so better optimize it.

Btw if you want to see a extremel fast sqrt function :smile:

1 Like

Ha I know that one, I just send it to people that think they know their shit. The wiki version is better though, complete with the famous // what the fuck? comment :smile:

The funny thing is that noone really knows its origins, everyone just “saw it elsewhere”. Perhaps someone went back in time and pasted it from the future :smiley:

Here is another hint for fast 3d / 4d matrices: If scale == (1.0,1.0,1.0) then M^-1 == M^T.
In other words: if the diagonal is 1.0,1.0,1.0 then the inverse matrix is the transposed matrix.
Don’t know if this is already in the FastMath library or not.

Here is an example:

M =
/ 1.0 m1 m2 \
| m3 1.0 m5 |
\ m6 m7 1.0 /

M^-1 == M^T =
/ 1.0 m3 m6 \
| m1 1.0 m7 |
\ m2 m5 1.0 /

:chimpanzee_smile:

I know this trick from a book about physics engines for games…

Same with gcc and divisions by a constant:
They use crazy bitshifts and magic numbers when one of the two params is constant at compile time (Note: This is why you all should use final more often :P)

Another simple one (which is even hard to understand) is, if you want to divide by a power of two:
Let’s take 8 / 4 = 2:

1000b = 8d
1000b >> 2d = 0010b == 2d

That way you could also divide by e.g. 1024 (2^10 → >> 10)

Knew it! :chimpanzee_closedlaugh: :chimpanzee_smile:
Here is why that’s so funny to me:
Last week I made a bit-support-library.
I implemented all kinds of magic bit operations.

One of these tricks:
numer % (mod) 2^N == number & (2^N-1)

Example:

258 % 32 == 258 & 31
258 / 32 == 258 >>> 5

I think you are missing conditions,

M^-1 = M^t <=> M*M^t = Id

Of course… it only works if it’s an orthogonal matrix (vectors inside are perpendicular) with normalized vectors (vectors inside have length == 1). This is the typical matrix that we use in 3d computer graphics… (and simulated physics) + the scaling == (1,1,1) is also usually true (you usually pre-scale in Blender or via a tool and should rarely change size during game). So it appears quite often (especially in physics - scaling doesn’t make sense other than for velocity vectors - and we save magnitude separate usually). On the other hand - since we use quaternions - it might not be that important to have this shortcut.

Regarding the use final more often.
Java 8 here, effectively final.
Also the JIT can do some kind of these optimisations since long ago, even if it is not a constant, but a often repeating value it might make a special case native compile of that method.