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

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

The single precision thresholds are where the Qt demo code stops displaying
the cube and they are also near the critical value for xZ1 and xZ2 in
gl-render.cc. Here are some random scenarios i tested:

Octave plot is incorrect (xZ1, xZ2):
>> single(70710676.618654922) - single(70710679.618654922)
ans = 0

Octave plot is correct (xZ1, xZ2):
octave:1> single(56568540.994924024) - single(56568543.994924024)
ans = -4

Simple Qt demo program plot is incorrect (farVal, nearVal):
>> single(4e+7 + 2.0) - single(4e+7 - 2.0)
ans = 0

Simple Qt demo program plot is correct (farVal, nearVal):
>> single(3e+7 + 2.0) - single(3e+7 - 2.0)
ans = 4

But hold on, there is still more! Do you remember fix of bug #54551? Now look
at this:

octave:1> daspect ([1, 1, 1]);
octave:2> xlim ([-1e11, 1e11]);
octave:3> ylim ([-1e11, 1e11]);

xZ1 = std::max (-1e6, x_zlim(0)-(x_zlim(1)-x_zlim(0))*100.0);
xZ2 = std::min (1e6, x_zlim(1)+(x_zlim(1)-x_zlim(0))*100.0);
m_glfcns.glOrtho (0, vp(2), vp(3), 0, xZ1, xZ2);

(gdb) print *x_zlim.rep.data@x_zlim.rep.len
$1 = {707106781186.04761, 707106781187.04761}
(gdb) print xZ1
$2 = 707106781086.04761
(gdb) print xZ2
$3 = 1000000

octave:1> single(1000000) - single(707106781086.04761)
ans = -7.0711e+11

Surprise is that the plot in Octave is still invisible ;-) So my conclusion is
that the position of the object inside the view frustum plays also a role. It
looks like if the object distance to the clipping plane becomes too small over
camera object distance that the plot also becomes invisible. This problem is
solved for me if i increase xZ1 by a factor of 1.1

So maybe this is a good time to recall the observations:

1.) There is a lmitiation by the floating point expression "farVal-nearVal"
that becomes relevant for large xlim/ylim settings (in the order greater 1e+8)
and daspect([1,1,1])

2.) The position of the object with respect to the clipping plane over camera
object distance also plays a role.

3.) The statement

xZ1 = std::max (-1e6, x_zlim(0)-(x_zlim(1)-x_zlim(0))*100.0);
xZ2 = std::min (1e6, x_zlim(1)+(x_zlim(1)-x_zlim(0))*100.0);

has a problem in the transition region (xlim, ylim is in the order of 1e+5),
where "farVal-nearVal" can become zero, small or even reverse. The plot
becomes also invisible or causes render errors.

4.) There was bug #54551. Don't forget to fix this

5.) Unanswered question in comment #6:

> Is there a reason the proposed changeset breaks the existing symmetry
between lower and upper clipping limits?
Actually, the idea was to increase the distance between farVal and nearVal
only for the part of the scene which is in front of the camera, not behind.
The attached file #49697 solves problem 3.) but it does not solve problem


Reply to this item at:


  Message sent via Savannah

reply via email to

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