Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


What makes OpenGL right handed?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
63 replies to this topic

#21 szecs   Members   -  Reputation: 2176

Like
0Likes
Like

Posted 25 March 2010 - 09:08 AM

Quote:
Original post by jyk
Quote:
Original post by szecs
Maybe I will tell a totally dumb thing, but I'm a bit tired.
I think that makes openGL right-handed, is that if you don't apply any transformations (identity as model-view and projection), a model made and viewed in a left handed editor would appear mirrored in onenGL in the said conditions.

Some one please clarify this.
I don't think that's right; if the projection matrix is identity, I don't think the visual output will be anything meaningful (in the general case, at least).
Most newbies don't even know about the projection matrix.
So the question still sands: Am I right in my previous post?

Sponsor:

#22 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 09:16 AM

Quote:
Original post by szecs
So the question still sands: Am I right in my previous post?


You are, you won't see much because a pixel would take the whole screen (see swiftcoder's post), but that doesn't mean the model isn't there, in a right handed coordinate system [smile].

#23 szecs   Members   -  Reputation: 2176

Like
0Likes
Like

Posted 25 March 2010 - 09:19 AM

Does that mean I have solved the problem?
Do I get promoted or something?

(BTW if the model is smaller than 1.0 unit, then it will shown nicely, the viewport (thus pixels) has nothing to do with the matrices.)

#24 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 09:32 AM

Well, actually I think you can also switch handedness by providing a higher value for the left parameter than the right parameter OR higher for bottom than top for glFrustum or glOrtho, still, it would default to right handed.

Quote:
Original post by szecs
(BTW if the model is smaller than 1.0 unit, then it will shown nicely, the viewport (thus pixels) has nothing to do with the matrices.)


Yeah, you're right.

#25 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 09:33 AM

Quote:
Original post by Kwizatz
Quote:
Original post by jyk
I said this same thing in another recent thread, but as far as I can tell, Direct3D/DirectX is no more left-handed than it is right-handed.


You may be thinking about row mayor vs column mayor notation
Nope, I'm thinking about handedness.

Also, there's no such thing as 'row-major notation', at least as far as I'm aware. Are you talking about row- vs. column-vector notation?

#26 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 10:05 AM

Quote:
Original post by swiftcoder
An identity projection matrix is just an unscaled orthographic projection.
You're right, it is. But, if I'm not mistaken, it's a left-handed orthographic projection, so I'm not sure that szecs's theory holds up.

#27 szecs   Members   -  Reputation: 2176

Like
0Likes
Like

Posted 25 March 2010 - 10:17 AM

It's not the right or left handedness that is important, the important thing is that it is defined. If you have a coordinate in a right-handed coordinate system, the same coordinates will mean the point (represented by the coordinates) will be mirrored to on of the planes, in a left-handed CS. So you can define the handedness.

BTW the identity projection is same-handed as the identity modelview AFAIK. (I played around with shadow mapping matrices, and it didn't matter, if everything is applied in modelview (and the projection was identity), or the opposite, but I may remember wrong(ly?)).

Please correct my grammar.

#28 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 11:00 AM

Quote:
Original post by jyk
Nope, I'm thinking about handedness.


fair enough.

Quote:
Original post by jyk
Also, there's no such thing as 'row-major notation', at least as far as I'm aware. Are you talking about row- vs. column-vector notation?


I think there is, the way I understand it it has to do with whether the i and j in matrix notation Aij represent a column or a row, probably the same thing you mean with vector, but I could be wrong.

#29 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 11:03 AM

Quote:
Original post by jyk
Quote:
Original post by swiftcoder
An identity projection matrix is just an unscaled orthographic projection.
You're right, it is. But, if I'm not mistaken, it's a left-handed orthographic projection, so I'm not sure that szecs's theory holds up.


I think you are mistaken, what part exactly of a matrix tells you which handedness it belongs to? the 1,0,0 vector could point in the right direction just as well as it could to the left (or up, down,forward,backward for that matter).

#30 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 11:13 AM

Quote:
I think there is, the way I understand it it has to do with whether the i and j in matrix notation Aij represent a column or a row, probably the same thing you mean with vector, but I could be wrong.
Matrix majorness and vector notation are two different things. 'Majorness' refers to the i and j thing you mentioned, while vector notation convention deals with whether vectors are represented as column matrices (Nx1) or row matrices (1xN).

I've never heard the phrase 'row-major notation' used, and to me at least, matrix majorness doesn't really seem like a notational issue (rather, it's a programming detail having to do with how things are represented in memory). But, I suppose it's just semantics.

In any case, there are (at least) three different issues at play here - coordinate system handedness, matrix majorness, and vector notation. They're often conflated with one another, but despite the fact that they're interrelated in some ways, they're essentially orthogonal.

#31 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 11:27 AM

Quote:
I think you are mistaken, what part exactly of a matrix tells you which handedness it belongs to? the 1,0,0 vector could point in the right direction just as well as it could to the left (or up, down,forward,backward for that matter).
I'm assuming the convention adopted by both OpenGL and Direct3D that +x is to the right and +y is up in view space.

You're right of course that a matrix with no spatial context has no (spatial) handedness, per se. However, the transforms that are applied in both OpenGL and Direct3D do have a context (the graphics pipeline), and that is the context in which we're considering the handedness of the projection transform.

Just as a point of reference, consider the DX math library functions D3DXMatrixOrthoLH() and D3DXMatrixOrthoRH(). Given a 'unit' orthographic projection, the former produces:
1  0  0  0
0 1 0 0
0 0 .5 0
0 0 .5 1
While the latter produces:
1  0  0  0
0 1 0 0
0 0 -.5 0
0 0 .5 1
There are some differences due to how the canonical view volume differs between the two APIs, but the important thing to note is that the sign of element 33 differs depending on the handedness. If we were using the OpenGL convention for the view volume, the above matrices would instead be identity, and identity with element 33 negated, respectively. This is what I'm referring to when I say that the identity matrix represents a left-handed orthographic transform. (Again, in the context of the standard graphics pipeline.)

#32 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 11:42 AM

Quote:
Original post by jyk
I'm assuming the convention adopted by both OpenGL and Direct3D that +x is to the right and +y is up in view space.


Yes, and OpenGL's convention is that -z is forward in view space, which makes it right handed. Direct3D, I assume has +z as forward, therein lies the difference.

Quote:
Original post by jyk
There are some differences due to how the canonical view volume differs between the two APIs, but the important thing to note is that the sign of element 33 differs depending on the handedness. If we were using the OpenGL convention for the view volume, the above matrices would instead be identity, and identity with element 33 negated, respectively. This is what I'm referring to when I say that the identity matrix represents a left-handed orthographic transform. (Again, in the context of the standard graphics pipeline.)


Something doesn't sound right to me in your explanation, it seems like D3D being left handed would properly generate a negative M33 element to switch from its native left handed to right handed one, but I would expect OpenGL to get the opposite results you mentioned, identity for right handed, identity with negative one (-1) in M33 for left handed.

The whole point of this is that while OpenGL doesn't force you into right handed coordinates, it takes more effort from your part in order to use a left handed system.

#33 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 12:05 PM

Quote:
Yes, and OpenGL's convention is that -z is forward in view space, which makes it right handed. Direct3D, I assume has +z as forward, therein lies the difference.
Right, but the question being asked in this thread is, where does that convention come into play? Is it just in the various transform convenience functions that the API provides?

Another way to ask the question might be (using Direct3D as an example), in what way is Direct3D 'more' left-handed than it is right-handed? Can you point out exactly where in the pipeline its 'inherent left-handedness' comes into play?
Quote:
Something doesn't sound right to me in your explanation, it seems like D3D being left handed would properly generate a negative M33 element to switch from its native left handed to right handed one, but I would expect OpenGL to get the opposite results you mentioned, identity for right handed, negative M33 for left handed.
Nope, try out the following code:

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-1, 1, -1, 1, -1, 1);
float m[16];
glGetFloatv(GL_PROJECTION_MATRIX, m);
for (size_t i = 0; i < 4; ++i) {
for (size_t j = 0; j < 4; ++j) {
std::cout << m[i + j * 4] << " ";
}
std::cout << std::endl;
}

The output will be (give or take a negative 0):
1 0  0 0 
0 1 0 0
0 0 -1 0
0 0 0 1
In other words, aside from the z range issue, the results are the same in both APIs: +33 for left handed, -33 for right handed.

I think it might be useful to forget about the gl and glu convenience functions and about the DX math library, and just consider the most up-to-date version of each API. In the programmable pipeline, there is no model matrix, no view matrix, and no projection matrix; there is only what you do in the vertex, geometry, and fragment programs, which is completely up to you. In this context (that of the programmable pipeline with no help from utility functions or from the fixed-function pipeline), is Direct3D still 'left handed'? Is OpenGL still 'right handed'?

My own suspicion is that the answer is no; that at the very least, with the modern programmable pipeline, the idea of each API having its own 'inherent handedness' is essentially meaningless.

However, I don't claim 100% certainty, and at this point, it looks like if I want to try to prove my theory, I'm going to have to dig into the respective pipelines a bit and provide some more concrete examples :)

#34 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 02:14 PM

You know what? I don't know anymore [smile], the man page for glOrtho seems to hint that you should pass near and far as negatives, or in your example near as 1, far as -1 which would result in the identity matrix, I tested changing the values around in my GUI, and saw no difference. Makes sence since -z is forward in OpenGL.

Anyway, there is a solution to settle this, implement what szecs suggested, that is set projection to identity, make no mirror transformations or negative scales in modelview draw the axes at the origin with 0.1 lengths and see in which direction z points when y is up and x is right, that's it.


#35 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 25 March 2010 - 02:53 PM

Quote:
the man page for glOrtho seems to hint that you should pass near and far as negatives, or in your example near as 1, far as -1 which would result in the identity matrix
Hm, I don't read it that way. It says, 'These values are negative if the plane is to be behind the viewer', which I take to mean that negative values (e.g. -1) correspond to planes that are behind the viewer. Therefore, a near value of -1 and a far value of 1 would make sense.

Also, gluOrtho2D() sets 'near' to -1 and 'far' to 1, so I think it's pretty safe to say that negative distances are intended to be behind the viewer and positive distances in front.
Quote:
Anyway, there is a solution to settle this, implement what szecs suggested, that is set projection to identity, make no mirror transformations or negative scales in modelview draw the axes at the origin with 0.1 lengths and see in which direction z points when y is up and x is right, that's it.
This isn't quite the same thing, but I put together the following little test program:

#include "SDL.h"
#include "SDL_opengl.h"

int main(int, char*[])
{
SDL_Init(SDL_INIT_EVERYTHING);
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);
SDL_SetVideoMode(400, 400, 0, SDL_OPENGL);
glEnable(GL_DEPTH_TEST);

bool quit = false;
while (!quit) {
SDL_Event event;
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT) {
quit = true;
}
}

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glColor3f(1, 0, 0);
glBegin(GL_TRIANGLES);
glVertex3f(-.75, .25, .5); glVertex3f(.75, 0, .5); glVertex3f(-.75, -.25, .5);
glColor3f(0, 1, 0);
glVertex3f(-.25, -.75, .75); glVertex3f(0, .75, .75); glVertex3f(.25, -.75, .75);
glEnd();
SDL_GL_SwapBuffers();
}

SDL_Quit();
return 0;
}

All transforms are left at identity. A red triangle is drawn at z = .5, and a green triangle is drawn at z = .75. Here's the output:



Note that the red triangle is in front of the green one, which would seem to suggest that z is increasing away from the viewer. In other words, the coordinate system in this example is left-handed.

So, that's the empirical (assuming the example isn't flawed in some way), but let's go ahead and look at the theoretical.

In OpenGL, normalized device coordinates are left-handed. Obviously just because it says so on the internet somewhere doesn't make it true, but for what it's worth, it's stated here that the NDCS is left-handed.

Now, if all transforms are left at identity, after the projection transform, all vertices will have a w value of 1; therefore, the division by w can be disregarded.

What we are left with is that all vertices are passed unchanged (except for clipping) to NDC space, which is left-handed. So if anything, it seems to me that if OpenGL has an 'inherent handedness', it would be left-handed, not right-handed.

So why is OpenGL said to be right-handed? The only reasons I can think of right now are that front faces are CCW by default in OpenGL (it has to be one or the other, after all), and that the convenience functions for which handedness matters (gluLookAt, glFrustum, etc.) build right-handed transforms.

As for Direct3D, the only reason I can think of for it being considered left-handed is that front faces are CW by default. Again though, if there's going to be a default, it has to be one or the other.

So for now at least, I'm going to stick with my assertion that aside from minor details such as default winding order (which are more or less incidental), neither API is any more right- or left-handed than the other. In fact, if one were forced to assign a 'default' handedness to each, it seems that they should both be considered left-handed, since if all transforms are left at identity, the geometry ends up in a left-handed coordinate system.

That said, I'm ready to be proven wrong (maybe one of our resident graphics gurus will step in and put this whole thing to rest).

#36 Kwizatz   GDNet+   -  Reputation: 1204

Like
0Likes
Like

Posted 25 March 2010 - 03:15 PM

Yes, you're right, I checked this too myself, I guess I got too hung up in the assertion that -z is forward in view space, which is even in the red book, anyway, this knowledge will come in handy for me.

gluPerspective definitely sets a right handed space, I wonder if that is true of glFrustum as well.

#37 szecs   Members   -  Reputation: 2176

Like
0Likes
Like

Posted 25 March 2010 - 07:32 PM

Okay, I am a bit confused.
What CS do Blender or 3ds Max have? I think right handed. So what happens if you load a small model into the test program?
Will the model look mirrored or not?
I could try it out myself, but I don't have time for it now unfortunately.

#38 haegarr   Crossbones+   -  Reputation: 4437

Like
0Likes
Like

Posted 25 March 2010 - 09:53 PM

Quote:
Original post by szecs
What CS do Blender or 3ds Max have? I think right handed. So what happens if you load a small model into the test program?
Will the model look mirrored or not?
I could try it out myself, but I don't have time for it now unfortunately.
Blender uses LHS, 3DS Max uses RHS (AFAIK).

Every application has in fact its set-up of projection (for the view local z to depth mapping), vertex winding rule, and depth test. You need to have your models accordingly to this set-up, or else some hiccup will happen.

Viewing a mirrored mesh is one possible outcome, yes. Assuming that the model is imported in the center of the world, and the camera looks from a distance at the center, and x and y are used in both the viewer as well as the content creation package for sideward and up, resp, and the scaling is suitable, then you'll see a mirrored model when the both applications uses different handedness.


All the discussion now is about whether the API itself introduces a handedness. But since all aspects that play a role can be re-programmed or, with OpenGL's newest specifications, have to be be programmed, the consensus seems me to be that there is no real handedness in OpenGL. Instead, the handedness comes from the way an application uses the API. So saying OpenGL uses RHS is substantiated in the history where the utility functions like glFrustum and glOrtho as well as the default winding rules and depth test were used widely by applications, and those functions and defaults have done a set-up for RHS.

#39 scgames   Members   -  Reputation: 1977

Like
0Likes
Like

Posted 26 March 2010 - 01:08 AM

Quote:
All the discussion now is about whether the API itself introduces a handedness. But since all aspects that play a role can be re-programmed or, with OpenGL's newest specifications, have to be be programmed, the consensus seems me to be that there is no real handedness in OpenGL. Instead, the handedness comes from the way an application uses the API. So saying OpenGL uses RHS is substantiated in the history where the utility functions like glFrustum and glOrtho as well as the default winding rules and depth test were used widely by applications, and those functions and defaults have done a set-up for RHS.
Haha, nicely said. You just summed up all of my previous rambling, disorganized posts in one nicely worded paragraph :)

#40 GaryNas   Members   -  Reputation: 134

Like
0Likes
Like

Posted 26 March 2010 - 03:32 AM

Quote:

All the discussion now is about whether the API itself introduces a handedness. But since all aspects that play a role can be re-programmed or, with OpenGL's newest specifications, have to be be programmed, the consensus seems me to be that there is no real handedness in OpenGL. Instead, the handedness comes from the way an application uses the API. So saying OpenGL uses RHS is substantiated in the history where the utility functions like glFrustum and glOrtho as well as the default winding rules and depth test were used widely by applications, and those functions and defaults have done a set-up for RHS.


Wow. There's been some really good discussion on this topic here.

I think that jyk's mention of face culling gives us a clue. I believe that clip space (i.e. post projection space, before homogenous divide which transforms us to NDC space) is hard coded in each API to be a specific handedness. Direct3D uses a left handed clip space and OpenGL a right handed clip space.

It's in this space that face culling and frustum clipping occurs. Frustum clipping is something we have no control over, so possibly at this point OpenGL expects a right handed system (i.e. looking down -z) to properly clip. Is this right?





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS