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: Markus Mützel
Subject: [Octave-bug-tracker] [bug #58956] Empty plot for certain xlim / ylim settings
Date: Mon, 24 Aug 2020 04:46:26 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Edg/84.0.522.63

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

Very good detective work.

I haven't tried your patch yet.

Tbh, I don't understand the reason for the segfault you see without the min
and max. Why do we need these (arbitrary) limits? Where does the segfault
occur?
The min and max were introduced to solve bug #54551. Maybe that can give a
clue:
https://hg.savannah.gnu.org/hgweb/octave/rev/2c42ed37cfc2

What is the reason for the segfault? Just a wild guess: Must the difference
between the z-clipping limits be larger that a certain fraction of its
average/minimum/maximum value?
The current approach limits the distance between the clipping planes. The new
approach extends it. Why do both *not* cause a segfault, but removing min and
max does?

Is there a reason the proposed changeset breaks the existing symmetry between
lower and upper clipping limits?
Would it make sense to extent the z-clipping limits symmetrically instead?

"xZ2" is the same in both branches. Maybe it could be moved outside the
conditional blocks?

The z-component of the camera position after running the first example in
comment #0 differs by a factor of approx. 20 in Matlab and Octave.
Matlab R2020a:

>> plot (0, 0, 'ro');
daspect ([1, 1, 1]);
ylim ([-1e5, 3e5]);
xlim ([-1e5, 1e5]);
get(gca, 'CameraPosition')

ans =

   1.0e+05 *

         0    1.0000    1.1180


Octave 5.2.0:

>> plot (0, 0, 'ro');
>> daspect ([1, 1, 1]);
>> ylim ([-1e5, 3e5]);
>> xlim ([-1e5, 1e5]);
>> get(gca, 'CameraPosition')
ans =

         0.00000    100000.00000   2236068.47751


That might be the reason why the original example exposes this bug (like you
already wrote in comment #3).

But I also think that we need to make sure that we don't clip important parts
from the scene (in particular not the plain with the axes in 2d plots).
IIUC, xZ2 (farVal) should not be smaller than xZ1 (nearVal). That happens in
the original example (see comment #3). So there most probably is an error with
the current logic.

    _______________________________________________________

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]