Document that OpenGL axis is inverted

[neclepsio]

I'm porting an application working with go-gl and go-gl/glfw, so I'm faily sure my OpenGL code is correct.
I looked for Qt/QML OpenGL documentation about the following issues, finding nothing (surely it's my fault) [1].

The first problem is depth testing (and maybe depth masking) gets reset at every paint (and what else?): it took me a while to find out, so I think it's worth documenting.

The main problem I have is the surface is upside-down (and maybe front-back?): normally, OpenGL origin is bottom-left, with QML (and Qt?) it's top-left, coherent with all the windowing systems I know.

To get my scene render correctly, I have to invert y in the projection matrix, but in this case all the normals seem inverted (Why? In my shaders the projection matrix is not used when calculating lighting... I have to work on that but has anyone any idea?).
Is modifying the shaders (in this case the projection matrix) the correct way to flip the view to be coherent with "classic" OpenGL?
Also in this case, I think it's worth documenting.

[1]: I just found "To start with, there are a couple of obvious problems with our starting point - the Qt is upside down and back to front" here: http://qt.developpez.com/doc/5.0-snapshot/quick3d-shadertut/

[cookieo9]

When you flip only one axis, the triangle vertices are presented in a
different "winding" order and so are considered backwards. IE: if you
specified a triangle's in Clockwise order, after flipping the axis they
will be in CCW order, and so the front and back faces will be swapped.

I'm not sure if this affects the normals, but it certainly does affect the
appearance, especially if you cull back-faces.

On Fri, Sep 5, 2014 at 1:04 PM, neclepsio notifications@github.com wrote:

I'm porting an application working with go-gl and go-gl/glfw, so I'm faily
sure my OpenGL code is correct.
I looked for Qt/QML OpenGL documentation about the following issues,
finding nothing (surely it's my fault) [1].

The first problem is depth testing (and maybe depth masking) gets reset at
every paint (and what else?): it took me a while to find out, so I think
it's worth documenting.

The main problem I have is the surface is upside-down (and maybe
front-back?): normally, OpenGL origin is bottom-left, with QML (and Qt?)
it's top-left, coherent with all the windowing systems I know.

To get my scene render correctly, I have to invert y in the projection
matrix, but in this case all the normals seem inverted (Why? In my shaders
the projection matrix is not used when calculating lighting... I have to
work on that but has anyone any idea?).
Is modifying the shaders (in this case the projection matrix) the correct
way to flip the view to be coherent with "classic" OpenGL?
Also in this case, I think it's worth documenting.

[1]: I just found "To start with, there are a couple of obvious problems
with our starting point - the Qt is upside down and back to front" here:
http://qt.developpez.com/doc/5.0-snapshot/quick3d-shadertut/

—
Reply to this email directly or view it on GitHub
#96.

Carlos Castillo

[neclepsio]

Great! Thank you!

[niemeyer]

I'm aware of this behavior, and also had to adapt code before so it rendered properly. I'm not entirley sure about whether we should just document it, or whether we should invert the axis back. On one hand, we'd be making it more expected to OpenGL developers, but on the other hand we'd be making the OpenGL axis and the standard QML axis unrelated to each other.

In either case, I'll try to find a moment to investigate how the axis is inverted, so we can see the proper way to revert it back, either internally or in the paint code.

[neclepsio]

My work in porting my application from go-gl to qml has finished.

Y axis seems inverted in framebuffer.

What I did to get it back is multiplying by -1 the second element of the second row of the perpective matrix.

As cookieo9 suggested, triangles get "flipped", so you need change also gl.FrontFace.

When you're reading the framebuffer with gl.ReadPixels you have to take in account Y is inverted, so you don't have to do it on your own.

As a bottom line (unrelated to the issue, reported for reference), I get 45 fps, while with go-gl I get 60 fps.
This is top5 profiling results:

     324  42.2%  42.2%      409  53.3% runtime.cgocall
     175  22.8%  65.1%      175  22.8% runtime.futex
     144  18.8%  83.8%      144  18.8% runtime.usleep
      80  10.4%  94.3%      426  55.5% runtime.cgocallbackg
      26   3.4%  97.7%       26   3.4% ExternalCode

[niemeyer]

Thanks for those checks. I still haven't had time to investigate how Qt is inverting the axis, but will do so.

In terms of the benchmark, are you able to provide a benchmarking application? It doesn't have to be simple.. it just has to be realistic, and has to output a number I can see somehow. The new API was just born, and has never been optimized, so I'm not surprised the results aren't as good as elsewhere, but I'm happy to look at it. If you can, please open a separate issue about it.