octave-bug-tracker
[Top][All Lists]
Advanced

[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, 1 Nov 2020 09:07:49 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0

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

Markus, I wouldn't push this patch for now. It is not "clean" to do this
transformation, although it is technically allowed for orthographic projection
and actually solves some of our problems. But, if someone wants to implement
"perspective" (not implemented in Octave yet, but available in Matlab) the
shift into the origin will cause problems because of the perspective divide.
And: I did a test implementation of perspective (full implementation is tricky
because interface between bounding box and view port) in Octave and can
observe similar clipping artifacts like in glOrtho, which is not too
surprising. But then we have to solve this problem too. By the way, I can
reproduce the accuracy problems of "glClipPlane" in an offline Qt demo code
that is completely independent from the Octave source code. So we can add
glClipPlane as a new and separate problem to the OpenGl Open Point list.

More and more points are coming to light and I think it is a bit difficult to
continue the OpenGl discussion here because there are quite some points and
questions. I have started to prepare a presentation on the topic (explanation
of update_camera, collecting the fall traps with respect to our observations
etc.), but could not finish the slide for our last octave developer meeting.
If there is interest, we could e.g. talk a bit more generally about the topic
in one of the next developer meetings. Or maybe discuss it in a workshop with
a reduced number of participants, since not everybody might be interested in
this topic.

JWE has the OpenGl back end on his wish list [1]. Currently, if I could make a
wish, I would remove all legacy glvertex, write everything to local memory
(allocated, double type), scale everything down, convert everything to GLfloat
and then pass everything to a VBO and let the vertex and fragment shaders do
the rest. But apart from the runtime, I have a doubt that simple normalization
will cure us of all the problems we have. It will heal us from axes larger
than an order of ^38, but probably not from clipping?

Any comments? Also from other members?

[1]: https://wiki.octave.org/JWE_Project_Ideas




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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