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

[Hg200]

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

Our posts are crossing, but i am attaching mine anyway to see the different
solutions ...

Thanks for the prototype! Just a shoot in the dark to get an idea about the
performance: If we keep the normalized difference between near and far around
two float epsilons it seems to fix the problem for axes and scatter graphic
objects and avoids the opengl errors too. However to have reliable code it is
probably advisable to add some more saftey margin.

++
const double opengl_eps = std::numeric_limits<float>::epsilon ();
const double sum = x_zlim(1) + x_zlim(0);
const double diff = x_zlim(1) - x_zlim(0);

if (2.0 * opengl_eps * sum > diff)
  {
    xZ1 = (0.5 - opengl_eps) * sum;
    xZ2 = (0.5 + opengl_eps) * sum;
  }
else
  {
    xZ1 = x_zlim(0) - 100.0 * diff;
    xZ2 = x_zlim(1) + 100.0 * diff;
  }
--

This approach is already much better as what we have. Although i haven't
checked all details (e.g. one of x_zlims can become negative but i think it
excludes with the true branch), i saw the problem with line plots is not
fixed. Sometimes lines are displayed, sometimes they are not. I don't know
what the trouble is, but to display lines under all conditions the near / far
values must be chosen much wider:

++
xZ1 = 0.49 * sum;
xZ2 = 0.51 * sum;
--

To check the problem run following code:

++
figure;
xlim ([-172099058766.5512 797603098357.2810]);
ylim ([-1.535202916065375e+11 2.103152628728371e+12]);
zlim ([-1 1]);
hold on;
line ([-1e+11 5e+11], [1e+12 2e+11]);
plot (0, 0, 'r*');
axis equal;
figure;
xlim ([-1.7e+11 7.0e+11]);
ylim ([-1.5e+11 2.1e+12]);
zlim ([-1 1]);
hold on;
line ([-1e+11 5e+11], [1e+12 2e+11]);
plot (0, 0, 'r*');
axis equal;
--

Also the command

++
xlim ([-1e42, 3e42]);
warning: opengl_renderer: data values greater than float capacity.  (1) Scale
data, or (2) Use gnuplot
--

still fails. But in Matlab it opens axes. So it looks like there other
limitations too. To get rid of all problems we probably need more than one
fix. Maybe need to normalize the OpenGl modeltransformation too?

I'm making slow progress with axes::properties::update_camera(). What i
understand is that the view point, target and upvector are calculated in the
first part. Depending on aspect ratio and displacement from the origin, the
OpenGl 4x4 matrices are then calculated by matrix-scalar and -sift operations.
The trick is to understand what exactly x_view, x_projection, x_normrender,
x_pre is doing. I have translated axes::properties::update_camera() from .c to
.m, but when i apply x_gl_mat1 to a random scene i still obtain garbage. Looks
like a bigger project for next vacation.



    _______________________________________________________

Reply to this item at:

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

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