Apache OpenOffice (AOO) Bugzilla – Issue 82871
silhouette border lines for 3D shapes in chart
Last modified: 2013-02-24 21:18:58 UTC
Some 3D charts look broken when the object borders are switched on because some lines are missing to complete the silhouette. I'll attach examples to illustrate the problem.
Created attachment 49083 [details] missing lines image
Created attachment 49084 [details] wanted lines
Created attachment 49085 [details] example doc with living charts
->Armin, the chart uses the property D3DReducedLineGeometry to show not to many lines, but the silhouette lines are missing in this context. I think the behavior for D3DReducedLineGeometry should be fixed/enhanced thus also the silhouette borders are displayed by the drawing layer.
AW->HIA: As already intensively discussed there are two possibilities: (a) Create the needed 3D geometry in chart2 (b) Support it in a 3D renderer (a) May be a bit complicated at the first look but will always work with all future renderers. (b) Needs special support for 'outlined' 3D objects in the 3D renderer. As a precondition we will need Primitives (see aw033 or 'http://wiki.services.openoffice.org/wiki/DrawingPrimitives' for progress). These will be part of 2.4/3.0. Then we need (c) a algorithm for doing 3D outlines. So this would be realizable after this (3.1?). The big disadvantage is that this will only work with our internal renderer (since supported there). One goal of primitives is to be able to e.g. support 3D hardware on target plattforms, what will happen. This is a big disadvantage of this solution. So i suggest the following investigations: 1, How expensive is (a) and may it be preferrable due to the conditions mentioned above? 2, How can (c) be done, investigate in algorithms Number (1) is a task for You (of couse i may help You on demand), number (2) can be done by me or You, but it would be a good preparation for me if there is already some Papers/knowledge about that when the primitives are ready. So please take (1) into account especially with the possibility to have it work in all future /extern 3D renderers. Also a look at possibilities for (2) would be nice. Please keep me informed about the results.
->Armin, it is internal knowledge of the drawing layer transformation which point of the 3D object will happen to be on the silhouette after transformation to 2D screen. When I create a single 3D shape via UNO API I don't have the knowledge about that. Thus I see no way to create extra objects for the missing lines. What do you mean with I can do (2)? I am a user of the Draw API and not an expert or a provider of a 3D renderer. So I will need your expertise to have this fixed in a 3D renderer.
AW->IHA: This is not what i tried to talk about. I try to manage the needed changes so that all profit and we get a good result. You do not only use the 3D API, You also use the SdrObjects involved and of course have the possibility to access all involved 3D projection mathematics. The problem would be to calculate them, but they are completely provided, You may just use them, it's not too complicated (not more then the 3D geometry creation You use today). You need to use non-API stuff anyways since i am not aware of setting a property like 'D3DReducedLineGeometry' over API, but i may be wrong here. My suggestion was just that You think about one of two possibilities - creating the needed geometry in the chart2 which would allow to not extra-handle it in all future 3D renderers. I think this is an important point which makes sense. Am i wrong? It is sad if this is not possible and will not speed up the support of it. I also did not talk about You doing (2), i explicitely wrote that it can be done by me or You. I just tried to explain that it would have advantages if it would be possible to investigate in those possibilities and it would just safe time. Well, so at least, i need to know then: - how can it be detected that 'D3DReducedLineGeometry' is activated at an object? And i again want to ask You to think about possibility (a) for which i already offered You help in my last mesage. No one forced You to do that on Your own.
I do not use non API stuff to set D3DReducedLineGeometry. It is an UNO property (the string is defined as UNO_NAME_3D_REDUCED_LINE_GEOMETRY in svx). It was a huge effort to switch to UNO API and become more independent from the concrete drawinglayer imlpementation. As we decided to do that in the chart, I had your support, because it helps to make changes in the underlying code more independent. We shouldn't waste this effort just to overcome this missing feature in the 3D renderer. So I think option (a) is actually no option. If an SdrObject knows all that is neccessary, it sounds like the implementation of the SdrObject could create the needed extra geometry?
AW: Pure API usage is very good and will surely pay in the long term. I would even do changes to further support this. I just remembered that there was some direct SdrOject uage ?!? If not, even better! It is also good that the flag in question is already supported there and also already used (e.g. set when needed)? This indeed leads to creating the needed geometry inside the 3D SdrObject (or xShape) before sending it to the renderer (a) or adapt the renderers (b). This will then be my decision and investigation. There is a caveat which comes to my mind: - The granularity is limited to a single 3D xShape. Are all of Your geometries which need this a single 3D shape? If there are composed ones, each will get it's own frame and the composition will not look good.
Cool. The 3D cones and cylinders in the chart are each created as a com.sun.star.drawing.Shape3DLatheObject. The 3D pie and donut segments are created as com.sun.star.drawing.Shape3DExtrudeObject. For all those objects and only for those objects the property UNO_NAME_3D_REDUCED_LINE_GEOMETRY is set to true.
AW: Thanks for the info, this should be no hindrance then.
Added note
AW: Fixed with aw033 (primitives), solved geometrically. Closing.
.