Issue 98295 - 3D charts are too dark
Summary: 3D charts are too dark
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: DEV300m30
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2009-01-20 18:31 UTC by IngridvdM
Modified: 2009-02-26 10:03 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
file showing the problem (44.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-01-20 18:32 UTC, IngridvdM 		no flags Details
example with and without shading (119.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-01-21 10:24 UTC, IngridvdM 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description IngridvdM 2009-01-20 18:31:49 UTC 
Load the attached document and look at the 3D chart on the left side.
Since dev300m30 it is very dark. On the right side there is a metafile showing
how the chart looked like in OOo 3.0.
Comment 1 IngridvdM 2009-01-20 18:32:41 UTC 
Created attachment 59537 [details]
file showing the problem
Comment 2 IngridvdM 2009-01-20 18:37:49 UTC 
The objects that are too dark now are created as shapes of service
com.sun.star.drawing.Shape3DPolygonObject.
If I change the direction of the normals that I set to property
UNO_NAME_3D_NORMALS_KIND within the chart then the illumination is correct again.
But as I haven't changed anything here within chart this should be changed
behind the UNO API within draw thus other API users to not struggle over the
same issue.
Comment 3 IngridvdM 2009-01-21 10:22:32 UTC 
Investigated further I found out that it is not that simple just to reverse the
normal. That does only help in case there is shading switched on. Without
shading the 3D elements remain dark.
I'll attach an example with two charts - one with and one without shading.
Comment 4 IngridvdM 2009-01-21 10:24:00 UTC 
Created attachment 59558 [details]
example with and without shading
Comment 5 Armin Le Grand 2009-02-02 14:30:05 UTC 
AW: Checking the whole geometry preparation chain for 3D geometry, also the
rendering proccess. There must be some difference in handling the normal
creation. Maybe it has to do with automatic normal creation in the decomposers
(e.g. in SdrExtrudePrimitive3D::createLocalDecomposition(...))...
Comment 6 Armin Le Grand 2009-02-02 15:48:48 UTC 
AW: Problem found. Unfortunately, the definition of SdrObject E3dPolygonObj
which allows a free 3d geometry definition was defined wrong topologically in
relation to it's plane normal and 3D visibility when it was invented a long time
ago. Since the API allows reation of this SDrObject type, it is not possible to
simply change this definition. Only the chart should use it, and at least this
object type only exists at Runtime (is not saved and/or loaded in any
FileFormat). Still someone external may have used it in it's API. To not risk
wrong 3D lightings, i have to switch the orientation of the polygon when
creating the needed SdrPolyPolygonPrimitive3D in
ViewContactOfE3dPolygon::createViewIndependentPrimitive3DSequence(). Checking
further...
Comment 7 Armin Le Grand 2009-02-02 15:53:49 UTC 
AW: Also added some data processing and lifetime optimizations to the
DefaultProcessor3D::impRenderPolyPolygonMaterialPrimitive3D implementation. Also
centralized tooling to work on normals on the primitive creation level. Added
support for normal preparations to SdrPolyPolygonPrimitive3D, too.
Testing...
Comment 8 Armin Le Grand 2009-02-02 17:02:35 UTC 
AW: Works well, committed. Done.
Comment 9 Armin Le Grand 2009-02-11 11:36:59 UTC 
AW->WG: Please review. Simplest is to use the bugdoc which shows a direct
comparison.
Comment 10 wolframgarten 2009-02-11 13:36:21 UTC 
Verified in CWS.
Comment 11 wolframgarten 2009-02-26 10:03:00 UTC 
Tested in OOO310_m3. Closed.