Sorry, but the matrix presented was column-ordered, however, this would make no difference.
Good point, JoeJ. I just made the following test:
float vMat =
-0.99064791 , 0.13169301 , 0.035664752 , 0,
2.6822096e-007 , -0.26139921 , 0.96523124 , 0,
-0.13643673 , -0.95620453 , -0.25895494,0,
0.00000000 , 0.00000000 , 0.00000000, 1.0000000
Vector3F sx = mat*Vector3F::UNIT_X;
Vector3F sy = mat*Vector3F::UNIT_Y;
Vector3F sz = mat*Vector3F::UNIT_Z;
Vector3F tsz = sx^sy; //cross product
float fAngle = tsz*sz;
based on the assumption that, on a right-handed coordinate sys, Z = X x Y ( cross product ), it should verify that fAngle = 1. However, after checking, turned out that fAngle is -1.
Indeed, the matrix includes a mirroring.
Strange that the matrix comes from a POD file exported by PowerVR in 3DMax. Any idea on what to do in this kind of situations? My best guess at the moment is to alter the scaling component of the TRS ( since scaling is computed as a length of a vector, taking the positive value ), to reflect the mirroring component. Anyone have a better idea ( which component of the scaling should have the sign inverted )?
I don't need 'nice slopes', since my grid of 256x256 is much smaller than my 3d world. I am using interpolation functions to create the smooth surface. I just want every texel to contain 3 floats and I want o access them as memory data. Here is a snippet from my shader:
#define OPENTG_HEIGHTMAPRES 256
float xn = X / OPENTG_SUBCELLSIZE;
float yn = Y / OPENTG_SUBCELLSIZE;
unsigned int i = (uint)floor( yn );
unsigned int j = (uint)floor( xn );
float u = fract(xn);
float v = fract(yn);
if( OPENTG_HEIGHTMAPRES == i )
v = 1;
if( OPENTG_HEIGHTMAPRES == j )
u = 1;
vec4 vH00 = GetVertCellParameters( i, j );
vec4 vH10 = GetVertCellParameters( i + 1u, j );
vec4 vH01 = GetVertCellParameters( i, j + 1u );
vec4 vH11 = GetVertCellParameters( i + 1u, j + 1u );
/*do something with the vec4's
they contain infos of height values in i, j cell and gradient information
it seems there are problems if some of those values are negative - the rendering looks somehow like it renders part of the scene and then stops rendering anything else in a certain point.
thanks for the answer, to make everything more clear, I was using uniforms for this and invoking a vertex shader for each terrain quad that project, in the XY plane, into an original grid location. That was very slow and wasn't taking advantage of the fact that the grid never gets modified.