Thanks again everyone.
Porting is coming along very nice and I'm happy with the results so far, as the OpenGL version runs faster than D3D, probably due to badly written D3D code on my side or the simplicity of GLSL shaders I use for now. Anyway I have another question.
I have entities which transformation is a D3DXMATRIX and I want to use that matrix for my OpenGL version of the renderer.
I did this already with my D3D view matrix, which is a D3DXMATRIX by multiplying it with a (1,1,-1) scaled matrix

D3DXMatrixScaling(&sca,1,1,-1) ; 
 OGLMatrix = g_Camera->view * sca ;

I load this into OpenGL and it works as a MODEL_VIEW matrix which has the MODEL part identity, so all my meshes lie in origin with no scaling and rotation factors, but I can move the camera around correctly.

Now I need to involve the meshes transform matrices from D3D so they are placed, scaled and rotated in the world, but I'm missing something probably because I get incorrect results.
This doesn't seem to work as expected :

D3DXMatrixScaling(&sca,1,1,-1) ;
  for(int i = 0 ; i < pOGLMeshes.size() ; i++ )
   {       
OGLMatrix = pOGLMeshes[i]->d3dMatrix * g_Camera->view * sca ;
g_pOGLRenderer->RenderMesh(pOGLMeshes[i] , &OGLMatrix[0] ) ;
   }

If I have a D3D model and view matrices, how am I supposed to concatenate them correctly, so I can load them in OpenGL as MODELVIEW matrix ?

Thank you.

d3d:

model * view * projection

ogl:

projection * view * model OR

projection * modelview

(reverse order)

This is because OGL uses column major matrices.

http://en.wikipedia.org/wiki/Column-major_order#Column-major_order
related:
http://www.songho.ca/opengl/gl_transform.html

d3d:
model * view * projection
ogl:
projection * view * model OR
projection * modelview

(reverse order)
This is because OGL uses column major matrices.
http://en.wikipedia.org/wiki/Column-major_order#Column-major_order
related:
http://www.songho.ca/opengl/gl_transform.html

D3DX uses row-major storage for it's matrices, but by default HLSL uses column-major storage for it's matrices -- the Microsoft Effects framework handles the conversion from one storage method to the other.
GL/GLSL also use column-major storage.

Also, the choice of whether you store your matrices using column-major storage or row-major storage has no effect on your math. This is only a choice of how your perform your 2D array indexing for storage only (at the lowest level of abstraction -- storing items in linear RAM). At the level of abstraction where you're working with mathematical matrices, both methods should behave the same, no matter how their storage mechanism is implemented -- they're both different ways of storing a matrix, there's no such mathematical thing as a row-major matrix or a column-major matrix, just matrices.

The thing that ends up causing you to reverse your mathematics is actually whether you choose to interpret an n-Dimensional vector as a mathematical row-vector (1*n matrix) or a mathematical column-vector (n*1 matrix). Again, in either case the storage mechanism has no effect, your vectors will likely be stored in row-major order, but you can mathematically interpret those bytes as a row-vector or column-vector.

D3DX (and fixed-function D3D) interpret vectors as row-vectors -- so a Float4 becomes a 1-row by 4-column matrix, and mathematically a 1x4 matrix has to be on the left side of a 4x4 matrix when multiplying, which forces you to use that order in your math.

Fixed-function GL interprets vectors as column-vectors -- a 4-row by 1-column matrix, which mathematically has to be on the right side of a 4x4 matrix.

When writing you HLSL/GLSL code, you can choose to use either convention. Shader-based D3D/GL do not force you to use one convention or the other.

Also, as I touched on before, HLSL and GLSL default to using column-major storage for their matrices (and row-major storage for their vectors), but this is just a storage detail, which doesn't affect your math. You can tell HLSL/GLSL to use either storage mechanism, e.g. by using the row_major keyword in HLSL.

http://fgiesen.wordpress.com/2012/02/12/row-major-vs-column-major-row-vectors-vs-column-vectors/

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-4-geometry/conventions-again-row-major-vs-column-major-vector/

Hodgman is correct here - we're not talking about any inner workings of the APIs here and it's incorrect to say that either API uses X; these are just notational conventions and each API is equally capable of either convention. See http://www.opengl.org/archives/resources/faq/technical/transformations.htm

So the reality is that when doing a porting job you can just use the same convention as before and everything will still work - no need to change anything at all as part of the porting job.

well, yeah that is the most correct way of saying it.

GL2.1 is missing some very important functionality:

• There is no reasonable render-to-texture API. You're stuck with using either pbuffers or glCopyTex(Sub)Image2D - the former of which will cause you to want to gnaw your own arms off, the latter of which works well enough but costs some additional performance.
• No instancing! I hope you weren't planning on using instancing in your code.
• There is no reasonable method of updating dynamic buffer objects; if you have any truly dynamic vertex data you may be as well off using old-school client-side arrays with system-memory pointers.
• There is no explicit specification of attrib locations or uniform locations in your shaders. This makes shader management a trifle more annoying than it should be.

All of these are present in D3D9, and while they could be pulled into a GL2.1 codebase via extensions, if you're aiming for full GL2.1 compatibility then you're going to need multiple code paths and you're not really just restricting yourself to GL2.1 anymore, are you?

So we're clearly in a position where you need to make a tradeoff - do you really want to be inclusive of those with older hardware (and at this stage note that for AMD/ATI and NV we're not just talking about a year or two here; that leaves Intel integrateds) at a high potential cost to your own productivity?