D3D shaders (HLSL) use column-major storage by default as well, just like GLSL. You've got to use "row_major float4x4 myMat;" or the options posted by imoogiBG above. Are you doing this in your working HLSL version?
Yes, I have
#pragma pack_matrix( row_major )
at the top of all of my shaders.
What's the multiply with 0.99999f for - to make sure the sky never touches the far plane?
Yep, thats what its for. I get heavy z-fighting unless for that line.
The vVertex variable in that code doesn't get used, is that right?
Well, that gets used later on for atmospheric scattering calculation, but nothing that affects the vertex position at all.
In the second code block, vNormal should have a w value of zero -- otherwise your normals will be affected by the translation row of the mPalette matrix!
Oh, I already wondered why my lighting on that model was off. I'm sure I checked that though, very weird. Thanks anyways, crosses another thing off the list :D
I haven't used GL for a while... is it possible that somehow when you update your uniform object / send the matrices to the shader, that the GL driver is somehow transposing them or modifying them in some way?
Thats very unlikely, since I'm using uniform buffers, and I'm uploading the data arbitrarily - or is there something that OpenGL does by itself that might change odering here?
I assume you suffer from the window co-ordinate problem: The book excerpt (I already mentioned it above) tells this with the "present transform" in eq. 39.1 and 39.2 and the following explanation "Window Origin". It mentions three ways to overcome it, all with some kind of drawback, of course.
Yes, you are totally right, thats the problem, at least with the reading in shader. I partially-countered this at first by inverting the coordinates for the fullscreen-pass, but that left me with even more problems. I'm now using step 2 by inverting the y-texture coordinate in shader, also I have to adjust the CPU-access of textures to account for the fact that textures are now stored upside down in regards.
Now all thats left is the vertex-transform problem, technically it is working with the old setting of reversing the multiplication order, but I sure would like to have it the right way, and know what this doesn't work in the first place...
