Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Another OpenGL (and Direct3D) matrices thread

  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.

  2. #12
    Member Regular Contributor
    Join Date
    Jan 2005
    Location
    USA
    Posts
    411
    ^I suppose in retrospect it really doesn't matter with glLoadMatrix as long as there is consistency

    That may be the crux of my memories

    Seems like OpenGL would've been better off to just omit glFrustum (and what else if anything?) if that is indeed the rub.

    If so...

    operator-on-the-left math order = P*V*M * vobj = vclip
    operator-on-the-right math order = vobj * M*V*P = vclip

    Is operator on the right notationally backwards? Because to me it definitely makes more sense for projection to be the last step. And that order tends to be more readable.
    God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.

  3. #13
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.
    You don't seem to be understanding how this whole "specification" thing works.

    The OpenGL specification defines apparent behavior. The `glUniformMatrix*` commands say, "If you provide matrices in column-major/canonical ordering, then I will upload them to matrix uniform storage in a way that will work in accord with GLSL. If you provide matrices in row-major/canonical ordering and set the `transpose` field to GL_TRUE, then I will upload them to matrix uniform storage in a way that will work in accord with GLSL."

    That is all the OpenGL specification says. If a particular GLSL implementation wants to use row-major/canonical ordering in the shader, then it will forcibly transpose everything you give it before uploading (effectively inverting the `transpose` field). But this is all transparent to you, because GLSL requires that `mat4x4[0]` to be the first column vector. So that implementation will have to build a column vector from 4 row vectors and return it when you take a `mat4x4` and index it.

    This is all an implementation detail that the user is not privy to. It is not possible to say what "you would expect to find in a hexeditor."

    Now yes, odds are good that the GLSL implementations will store the basis vectors as the vectors of the matrix. Odds are good that `mat4x4[0]` will not generate a column vector from 4 row vectors, but will just return a column vector because that's what the matrix stores. But you don't know that it will. Nor does OpenGL or GLSL provide any means to be certain that it will.

    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.
    I see no evidence of this. How do you define "work"? What values are you using? What are you rendering, what do you see before, and what do you see after?

    And most important of all, why do you insist on using confusing constructs like struct{ float u[4], v[4], n[4], o[4]; }; instead of a simple float[16]; like everyone else? I don't know what xform is, so I can't say what your supposed code is even doing.

    If you're going to test the ordering of something, use a 16-element floating point array, with no adornment from any matrix library or other things. Feed values into the array directly and pass it to OpenGL. Post the entire code example, top to bottom. And use code tags when you do.

    Or better yet, why don't you call glTranslate and then use glGetFloatv to pull the matrix you just generated out of OpenGL and let it tell you what the order is.

    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???
    Is what weird? The last four values should be the last column. You know, as in column-major/canonical ordering. Or row-major/transposed ordering. Or "xxxxyyyyzzzzwwww (where x is the components) in memory". Or any other way of saying that your "it will work" from before makes no sense.

  4. #14
    Member Regular Contributor
    Join Date
    Jan 2005
    Location
    USA
    Posts
    411
    ^I think this kind of nonsense speak may be why these kinds of threads are always so stupifying. I'm afraid I am going to have to give up at this point.

    Some of this is fragrantly unhelpful. So I won't gum up the thread anymore. Maybe Dark Photon can clarify xxxxyyyyzzzzwwww vs xyzwxyzwxyzwxywz with respect to OpenGL since we can't seem to agree that memory addresses or C structs for that matter are linear in nature

    Why not call glTranslate? Because it would be more work to setup a test application than its worth right now. Besides I do have a few resources to gawk at to supplant my chatting in forums now. I will get it straightened out one way or another.

    My take away (from the words here alone) seems like there is a 60% possibility I had OpenGL all wrong when posting the OP, and 40% I'm just being f'ed with for someone's dark amusement.

    But I do now remember at some point in my youth deciding to flip the indices all around in the matrix library I was using. I think there is a good chance I decided then to buck the OpenGL way. And that may well not be compatible with glTranslate and friends as I would not likely have been using them for anything 3D anyway much less mixing them with glLoadMatrix. I know SSE uses the xxxxyyyyzzzzwwww layout so odds are good I reckon that OpenGL does as well.

    EDITED: Maybe SSE swings both ways (http://fhtr.blogspot.com/2010/02/4x4...ion-using.html) but I remember an Intel presentation that explained the way to transform vertices en masse was to store them in memory so that the x components were all back to back and so on... I don't know if that is what the "streaming" bit means or not. I can't remember what application (optimization) I was trying to find for SSE, but whatever it was it didn't pan out.

    The last time I put down regular 3D programming "Longs Peak" was what everyone was talking about. I'm relieved to learn this afternoon that that didn't pan out.... at least because it means I can jump back into desktop OpenGL without having to research into anything too new
    Last edited by michagl; 11-09-2012 at 01:13 AM.
    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
  •