Irrlicht Engine

Greetings,
i've run into a some confusion about opengl's coordinate systems.
According to the specification, polygons are considered to be front-facing if they have counter-clockwise winding order(by default) in window coordinates(where right=+x, up=+y, intoscreen=+z, ie. a left handed coordinate system). This confuses me a great deal. Consider this triangle;
v1=0,1,0
v2=0,0,0
v3=1,0,0
It's winded counter-clockwise and has a normal along the positive z-direction, ie. into the screen, but will still be considered to be front-facing.
Why would a surface with normal pointing away from the screen ever be considered to be facing the screen? :S
I feel like i'm missing something essential and simple, but i can't wrap my head around what it might be.

Well that all depends on what you mean by front-facing doesn't it? I mean you could consider the normal to be the face of a polygon, and with backface culling that's exactly what you'll end up with. But by definition normal and front facing aren't related necessarily.

Perhaps if you thought of it as FORWARD-facing rather than front-facing it'd make more sense. As the programmer you're more like the driver than the bug about to hit the polygon windsheild??

IDK, I'd be surprised if it made sense at all, but it doesn't matter about the details of a thing as long as you understand how it works. You might be all fancy in c++ or basic but that doesn't require you to know assembly.

I mean you're really assuming that front means facing you right? And besides as far as I can determine from your example it could be laying flat on a plane. honestly one would have to see what you're talking about to give a legitimate answer.

OpenGL has a right-handed coord system, meaning the positive z-axis is going out of the screen. Hence, with the default OpenGL winding order the two match up correctly. In Irrlicht, it's just the opposite. We have left-handed coords, z-axis going into the screen, and the default winding order is clockwise.

Midnight wrote:...

Yeah, that's true. But i do think that OpenGL is designed so that surface normals and front-facing is supposed to match up. I don't understand the part about bugs and windshields. Regarding details and understanding, i do need to understand the details in order to understand. I mean, i could just observe what happens and be content with that, but i'm not. Sortof.

hybrid wrote: OpenGL has a right-handed coord system, meaning the positive z-axis is going out of the screen. Hence, with the default OpenGL winding order the two match up correctly. In Irrlicht, it's just the opposite. We have left-handed coords, z-axis going into the screen, and the default winding order is clockwise.

Well, OpenGL doesn't necessarily have a right-handed coordinate system(Or if it does, i'd like a source on that info); At least according to point 7 in appendix B in the 4.1 specification [1] ("OpenGL does not force left- or right-handedness on any of its coordinates systems.").
But since the z-buffer-values range from 0 to 1, with 1 being farther away than 0, positive z in ND-/Window-coordinates ought to mean that it's a left handed system at that point in the transformation pipeline. If so, then it must change from a right-handed to a left-handed coordinate system somewhere along the pipeline(assuming the untransformed system is right-handed).
This might or might not be related; Why is the ogl view-matrix almost always built so that it looks down along negative Z? This is rather awkward and sortof counter-intuitive to me.. Gahr, the most annoying thing is that noone actually seems to really know what is going on. It's very very tempting to just ignore the whole mess, change winding order and continue coding without understanding anything. :[


[1] http://www.opengl.org/registry/doc/glsp ... 100725.pdf

Yeah, it's the default projection matrices used by glu and other things which make most people say that OpenGL uses a right-handed system. We are using a left-handed coord system together with OpenGL, so yes, that's possible.