[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hg200
Subject: [Octave-bug-tracker] [bug #58956] Empty plot for certain xlim / ylim settings
Date: Sun, 20 Sep 2020 07:01:08 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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:


"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:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]