[Octave-bug-tracker] [bug #58956] Empty plot for certain xlim / ylim settings

[Hg200]

Follow-up Comment #19, bug #58956 (project octave):

file #49794, while not perfect, is definitely much better than what we
currently have implemented.

In the meanwhile I have completed the "reverse engineering" of update_camera
(). The object we want to plot is defined in the Octave frame that is also
displayed when the "axes ()" command is executed. I would call these
coordinates "world coordinates". At the other side OpenGl is an API for
rendering vector graphics. Unsurprisingly, the data to be visualized has to be
passed to OpenGL in a "normalized format". For example, the “view point”
and the "camera target" are on the Z axis. OpenGl provides two additional
“built-in” projection matrices with which the projection properties can be
augmented. glOrtho () is one of them, but basically the viewing direction is
still the z-axis. These are the camera coordinates and they are different from
the octave world coordinates.

Two important matrices are calculated in update_camera (). These are
"x_gl_mat1" and "x_gl_mat2". The matrix "x_gl_mat1" is what I would call the
"view matrix", and it is basically a transformation of the octave world
coordinates into camera coordinates. For a better understanding I have put
some pictures here:

https://wiki.octave.org/User:Hg200

"x_gl_mat1" is constructed from operation steps 1-8, which are a series of
translations, scalings and one rotation. The near / far values ​​(clipping
values) are finally calculated using a subset of these steps, i.e. a
"normalized" view matrix transformation. The near and far values ​​are
obtained by pushing a "unit cube" through this subset to get the "rotated"
plotbox in camera coordinates. Min and max values ​​are used to get the
max and min Z coordinates of the box.

To fix this bug, my idea was to change the view transformation so that the
near and far values ​​are calculated depending on the distance between the
view point and the camera target. However, a look at this section of code
shows that in the end this is basically the same as manipulating the near and
far values ​​in gl-render.cc. We're already doing that here.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58956>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/