Y not let Hardware do transformations?

Performance Tuning
#1

hi, y the hell, does Xith let the CPU do the matrix calculations and not openGL and the GFX-Card??
For example in the Class Transform3D:

private MatrixExt4f matrix = null;

public void rotX(float angle) {
setIdentity();
matrix.rotX(angle);
}

MatrixExt4f is a subclass from Matrix4f from the package javax.vecmath.

One of the main advantages of today’s GFX-Cards is that they do all the expensive calculations.
Pls, someone help me

#2

Your graphics card does this kind of transformation:

Matrix * Vector = transformed Vector

The time it would take to send the rotation command to the card and then sending the matrix back is probably much greater than the time it takes your cpu to do the same calculation.

#3

u don’t have to get the matrix back.
There r very effective calls in openGL directly for rotation, translation and scaling: glRotate, glTranslate and glScale. But theese commands r never used by Xith. Xith itself calculates a matrix and sends it to openGL by the much less efficient method glMultMatrix.
So, when I have to change (move, rotate) 100 objects in my scene the CPU has to do all the transformations, possibly hundreds.
Normally in openGL u walk through your scenegraph and call glRotate…

#4

I’m not sure but I suspect its partly to do with factoring in the JNI overhead…

You might consider posting this (or getting it moved) in the Xith forum, more likely to hit the right folks there.

Kev

#5

The hardware does do transformations (generally vector * matrix) - but you cannot EVER get the results back. This is the problem.

All 3D libraries require matrix maths on the CPU for moving things around (model matrices) animation, logic, etc. For example, boned animation requires several layers of matrix construction & concatenation. The final world matrices can then be passed to the GPU but you can’t get the GPU to do all that concatenation/construction as it does not have access to the main memory (where the animation data is stored) and does not know what algorithms you are using.

The logic behind this is the weight of numbers. If you have 100 objects each of 1000 vertices, then you only need a few hundred matrix operations per frame. The GPU however needs to transform 100,000 vertices per frame - hence the dedicated hardware to do it. The 100 odd matric calcs for moving the things around is trivial to a modern CPU.

Yet another reason is the fact that graphics cards actually do the work whilst you are rendering the NEXT frame. By staggering the load, this ensures a single point of synchronisation between the two processors (decoupling of parralel processes). This means that the GPU does not have to wait around when the CPU is busy and vice versa. Because of this decoupling, if you asked for a matrix op, you would not get the results until next frame - well after you needed it.

Hope this helps,

  • Dom