Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 14

Thread: Another OpenGL (and Direct3D) matrices thread

Threaded View

  1. #11
    Member Regular Contributor
    Join Date
    Jan 2005
    Location
    USA
    Posts
    411
    Quote Originally Posted by Alfonse Reinheart View Post
    It means nothing about what the "shader registers" do. It's all about what the specification says. It says that you are to pass column-major/canonical matrices, but you can pass row-major/canonical if you set `transpose` to GL_TRUE. If you follow this rule, OpenGL will interpret those matrices correctly, and matrix operations in the shader will operate as expected.
    Ok but you said converts to "row-major transposed" so that sounds like the target layout is "row-major transposed". In shaders as you well know the registers are 4D and a 4x4 matrix is 4 back to back, so you can plainly talk about them as memory just as you would expect to find in a hexeditor.

    Dark Photon and I have been telling you this for five posts now. The OpenGL 4.3 compatibility profile, folio page 432, very clearly and explicitly lays out what ordering it expects for the array of floats you pass in to MultMatrix and LoadMatrix. It has a diagram and everything. GLM uses this same ordering, which you can verify by looking at the output of `type_ptr`. You can create matrices in a compatibility profile and fetch the array of data to verify this.
    Can you link to that? A search turns up www.opengl.org/registry/doc/glspec43.core.20120806.pdf but I'm not finding anything on 432. Nvm; Bing does a better job with this query. Shouldn't have used Firefox's default anyway

    Will dig into this later

    If your experience has been something else, then all I can say is that you have dramatically misinterpreted your experience.
    Well if the memory layout is indeed xxxxyyyyzzzzwwww in memory then I admit that I have a reluctance to accept that because I worked exclusively with OpenGL for years and never fed matrices that looked like that to glLoadMatrix. But now it seems like you are gaslighting me, because I thought we agreed (like for for 5 posts) that the memory layout is identical to D3D (aside from what is a row and what is a column when summing the dot products) and D3D most definitely does not work that way.

    If I am to read your assertion correctly then there would have to be a way to pass an alternate layout to glLoadMatrix and still wind up with visually correct results.

    EDITED: I did some searching through old files and I can confirm now that glMultMatrixf with an xyzwxyzwxyzwxyzw memory layout will work. If we are disagreeing on that point, then let it be known that it will work.

    C Ex. struct{ float u[4], v[4], n[4], o[4]; }; //o holds translation in o[0], o[1], o[2]

    Though I suppose its possible the matrices are pre-transposed... will take more digging.

    EDITED: Nothing super conclusive, but I did turn up this:

    xform[12] = -eye.dot(x.u);
    xform[13] = -eye.dot(x.v);
    xform[14] = -eye.dot(x.n);

    xform.transpose3x3();

    glMatrixMode(GL_MODELVIEW);

    glLoadMatrixf(xform);

    The transpose I'm assuming is just part of an inversion trick. Clearly 12, 13, and 14 are loaded with translation values and sent directly to glLoadMatrix. Is that weird? Or are we in agreement but speaking past each other???

    EDITED: checked to be sure the [] operator was not overloaded.
    Last edited by michagl; 11-08-2012 at 11:12 PM.
    God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •