[Octave-bug-tracker] [bug #52260] Axes appear upside down with Qt5

[Dan Sebald]

Follow-up Comment #6, bug #52260 (project octave):

I'm writing some notes here for reference.

OpenGL can control the orientation of the coordinate system with what's called
"model view".  There is a function in Octave called 
setup_opengl_transformation() in gl-render.cc:


  void
  opengl_renderer::setup_opengl_transformation (const axes::properties&
props)
  {
#if defined (HAVE_OPENGL)

    // setup OpenGL transformation

    Matrix x_zlim = props.get_transform_zlim ();

    xZ1 = x_zlim(0)-(x_zlim(1)-x_zlim(0))/2;
    xZ2 = x_zlim(1)+(x_zlim(1)-x_zlim(0))/2;

    Matrix x_mat1 = props.get_opengl_matrix_1 ();
    Matrix x_mat2 = props.get_opengl_matrix_2 ();

#if defined (HAVE_FRAMEWORK_OPENGL)
    GLint vw[4];
#else
    int vw[4];
#endif

    glGetIntegerv (GL_VIEWPORT, vw);

    glMatrixMode (GL_MODELVIEW);
    glLoadIdentity ();
    glScaled (1, 1, -1);
    glMultMatrixd (x_mat1.data ());
    glMatrixMode (GL_PROJECTION);
    glLoadIdentity ();
    glOrtho (0, vw[2], vw[3], 0, xZ1, xZ2);
    glMultMatrixd (x_mat2.data ());
    glMatrixMode (GL_MODELVIEW);

    glClear (GL_DEPTH_BUFFER_BIT);

    // store axes transformation data

    xform = props.get_transform ();

#else

    octave_unused_parameter (props);

    // This shouldn't happen because construction of opengl_renderer
    // objects is supposed to be impossible if OpenGL is not available.

    panic_impossible ();

#endif
  }


which deals with model view.  There are lots of commands there, but it's
notable that props is passed into the routine.

The above routine is called by 


  void
  opengl_renderer::draw_axes (const axes::properties& props)
  {


which also has props as an input.  The draw_axes() is called by some routine
in gl2ps-print.cc (irrelevant).  It's also accessed via:


    const base_properties& props = go.get_properties ();

    if (! toolkit)
      toolkit = props.get_toolkit ();

    if (go.isa ("figure"))
      draw_figure (dynamic_cast<const figure::properties&> (props));
    else if (go.isa ("axes"))
      draw_axes (dynamic_cast<const axes::properties&> (props));


So props comes from the axes.

Going back a bit, the props info that seems pertinent is 

props.get_transform_zlim ();
Matrix x_mat1 = props.get_opengl_matrix_1 ();
Matrix x_mat2 = props.get_opengl_matrix_2 ();

The matrix 1 and 2 in question are interior to axes::properties and are
defined as the following in the routine update_camera():


  // Note: these matrices are a slight modified version of the regular
matrices,
  // more suited for OpenGL rendering (x_gl_mat1 => light => x_gl_mat2)
  x_gl_mat1 = x_view;
  scale (x_gl_mat1, xd/(xlimits(1)-xlimits(0)), yd/(ylimits(1)-ylimits(0)),
         zd/(zlimits(1)-zlimits(0)));
  translate (x_gl_mat1, -xo, -yo, -zo);
  x_gl_mat2 = x_viewport * x_projection;


OK, so this "light" demo does at least seem to be dependent on some specific
OpenGL transformations.  Some ideas:

1) The bug-reporter's OpenGL driver has a bug.
2) Somehow x_gl_mat1 and x_gl_mat2 are incorrect, such as mixing up the view
(x_gl_mat1) with the light source (x_gl_mat2).
3) Perhaps axes::properties::update_camera() is not being called prior to
drawing the axes but is called prior to drawing the tick marks and annotation.
 In such a scenario the x_gl_mat1 and 2 are initialized as Matrix().  Is that
all zeros?  Perhaps in most cases an all-zero transformation matrix is treated
like a unity-scale lower-left axis, but in the bug-reporter's case it is
unity-scale upper-left.

Noting what happens when the Qt light demo plots are rotated will be helpful. 
It could be an indication that view/light matrices are not valid for only the
initial plot.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52260>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/