Apache OpenOffice (AOO) Bugzilla – Issue 102611
3D wall filling is not painted
Last modified: 2017-05-20 10:29:13 UTC
Load the attached document with OOo 3.1 and press F9 to update the chart rendering or double click the charts. The 3D background wall should have a yellow filling but it is not painted anymore for the charts on the left side. Interestingly the filling is painted correctly when the wall gets border that is thicker than zero. That are the two charts on the right side. The filling was painted correctly until dev300m29. The first broken version is dev300m30.
Created attachment 62884 [details] example showing the problem
The filling is also painted correctly when right-angled-axes is switched off and thus the back wall is not exactly vertical.
AW: Added to CWS aw075, taking a look. Seems as if the back plane is numerically just slightly (e-10 range) outside the 3D volume; a typical numerical problem with doubles. Checking more deeply what happens...
AW: Does not happen with lines and line width since with 3D lines with line width the range of the complete 3D scene gest extended, thus the back plane is numerically no longer 'behind' the 3D range. The Z-Buffer uses a discrete integer-based range (in this case 0x0..0xffff), but has no explicit not-used value. Inited with 0 (so that everything in front of will be visualized) it works well, but in the described case the value of 0 is indeed used for the back wall. Since the Z-Buffer already has a 0 there, and 0 !> 0, the pixels are not added. This could be solved by using a special init value to know that the pixel is not yet used. This would not be nice since somehow extra memory would be needed. The other way is to use '0' as the init value and to use only the range 0x0001 .. 0xffff as Z-Buffer values, thus '0' would always be replaced by any pixel (as wanted with unused Z-Buffer entries). Checking that...
AW: In ZBufferProcessor3D::ZBufferProcessor3D the range for Z is defined by applying the needed transformations to the Z-Value which is in the range of [0.0 .. 1.0] originally. Applying a scale of 65535.0 would lead to a range of [0.0 .. 65535.0]. When using a 'unused' value of '0' we get a range of [1.0 .. 65535.0]. It has also shown that small numerical errors (smaller as basegfx::fTools::mfSmallValue, which is 0.000000001) happen. Instead of checking those by basegfx::fTools methods which would cost runtime, just add another 0.5 tolerance to the start and end of the Z-Buffer range, thus resulting in [1.5 .. 65534.5]. That range works well. It is also not a critical change since it happens in the local default 3D renderer; each other renderer or processor for 3D may use his own ranges; this is just a implementation-specific detail. Checking with other 3D scenes to make sure...
AW: Checked, works as expected. Checked in, done.
AW: Checked in test version, okay.
AW->WG: Please review, IHA may help, but the description is quite clear.
Verified in CWS.