[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, 27 Sep 2020 06:46:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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

Small update:

Concerning comment #22:
It looks like we have two clipping algorithms in the line primitive. One is in
"uint8_t clip_code (double x, double y, double z)", which can be found in
gl-render.h. This clipping routine is done in "draw_line" just before a line
vertex is sent to the OpenGl system via "glBegin(GL_LINE_STRIP)". It prevents
invisible points from being sent to the renderer. The other clipping is
performed in OpenGl via the OpenGl clipping planes and is used to cut off data
when the "pan" symbol in a figure is clicked and the figure is moved around.
The latter causes the problems because it unfortunately also cuts payload when
the axis are set large. The coordinates are probably given in world
coordinates, but since clipping is performed as one of the last operations,
the coordinates are internally transformed throughout the entire view matrix
most likely.

Concerning comment #20:
Just to see what happens, I moved the camera target to the origin [0,0,0] and
reverted the changes in gl-render.cc, i.e. x_zlim is now centered around z=0,
which is also the projection plane. Octave still shows the view point like
matlab when the command "get(gca)" is executed, but in orthographic
projection, the distance between view point and camera target has no meaning
since it has no influence on the image. So we can do this manipulation without
violating any view point properties. It turns out that we do it better if we
change the matrix: I do not see any clipping problems, and also large axes are
displayed correctly. "xlim ([-1e42, 3e42])" still does not work, as expected.
I don't know how "light" works, but at first sight it doesn't seem to be too
bad. I have attached an experimental "proof of concept" patch to see the
However there is a problem: Although not yet implemented in Octave, Matlab
also offers a perspective view ("projection" can be either "orthographic"
(default) | "perspective"). It should not be too difficult to implement
"perspective", although I failed on the first attempt. But if we move the
target to the origin because of the normalization problems, we will run into
big problems with "perspective", because unlike orthographic projection, the
distance between camera target and view point has very big impact in
perspective view. I wonder how the Matworks people solve this.

This topic will still require some engineering ...

(file #49866)

Additional Item Attachment:

File name: patch_camera_target_experimental.diff Size:2 KB


Reply to this item at:


  Message sent via Savannah

reply via email to

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