Problems with lighting of extruded custom-shapes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I want to improve lighting for extruded custom-shapes. I have examined how MS Office (MSO) does lighting of those shapes. Now I try to map that to the attributes of 3D scene and objects, which are used to render extruded custom-shapes. I see some problems and things incompatible with our current implementation (including my previous commit). So it would be nice to get some comments and suggestions from you.

If the OOXML 'scene3d' and 'sp3d' elements will be imported so, that extruded custom-shapes are used, the decisions here will influence that implementation too. Fontwork is affected too, because it is only a special mode of a custom-shape.

I know that for most of you working on LibreOffice is connected with making money. But maybe you have time to think about the problems anyway?


(A)
MSO attributes 'c3DKeyHarsh' and 'c3DFillHarsh'
API properties 'FirstLineHarsh' and 'SecondLineHarsh'
ODF attributes 'draw:extrusion-first-light-harsh' and 'draw:extrusion-second-light-harsh':

If a light is not "harsh", then MSO keeps only half the intensity value at the light and puts the other half to the ambient light. The light keeps to be "specular" in the sense of LO. That does not correspond to light attribute 'dr3d:specular' in our 3D engine, which is currently used.

ODF specifies, "The means by which the light is softened is implementation-defined." That means, that in addition we need to document, how we do it.


(B)
MSO attribute 'c3DShininess'
API property 'Shininess'
ODF attribute 'draw:extrusion-shininess':

This attribute has the same effect in MSO as the property "Specular Intensity" in the '3D Effects' dialog. That property is ODF style attribute 'dr3d:shininess'. Only the value ranges are different and a mapping would be not linear. But this attribute is currently not evaluated at all for extruded custom-shapes. Instead a value is build as 100 - "Specularity". (for "Specularity" see below)


(C)
MSO attribute 'c3DDiffuseAmt'
API property 'Diffusion'
ODF attribute 'draw:extrusion-diffusion':

The attribute works on the luminance of the fill color of the shape in MSO. I have not yet tested extrusion color. There exists a style attribute dr3d:diffuse-color (not to be confused with the same named light attribute) for 3D-objects in ODF. But this ODF attribute is not implemented in our 3D engine and the standard does not contain a description, how it should work. Values are only preserved from load to save by LO.
Default value is 1 in MSO and 0% in ODF.
MSO sets this attribute in addition to the 'fc3DMetallic' flag, if the user chooses the surface preset 'Metal', so we need to consider it for extruded custom-shapes.


(D)
MSO attribute 'c3DSpecularAmt'
API property 'Specularity'
ODF attribute 'draw:extrusion-specularity':

This attribute is currently mapped to property 'Specular color' in the '3d Effects' dialog. That property is ODF style attribute 'dr3d:specular-color'. ODF has as data type zeroToHundredPercent. MSO allows values larger as 1 and evaluates them. If the user sets surface preset 'Plastic' in the UI, then MSO sets 80000/65536≈122% for example.


(E)
MSO flag 'fc3DMetallic'
API property 'Metal'
ODF attribute 'draw:extrusion-metal':

The ODF standard specifies,
"•false: the specular color for the shading of an extruded shape is white.
•true: the specular color for the shading of an extruded shape is gray (red green and blue values of 200) instead of white and 15% is added to the specularity."

But "specular color" is not defined in the standard. It cannot be interpreted as "color resulting from draw:extrusion-specularity", because then that color would be either white or RGB(200,200,200), and it would conflict with interpreting 'specularity' as being 'draw:extrusion-specularity'. MSO has default 65536 for attribute 'c3DDiffuseAmt' and reduces it to 43712 in case of surface "Metal". Interpreting 'c3DDiffuseAmt' as "specular color" and 65536 as white and 43712 as gray would not result in RGB(200,200,200) but in RGB(170,170,170).



In case you want to test these MSO properties in a current MSO, then use a text document and save it to RTF. MSO provides then a UI for extruding shapes which uses these attributes known from the binary format, and you can edit the resulting RTF-file instead of working in binary format. LO cannot import the shapes in the RTF-file directly. Instead let MSO save it to doc-Format.

Kind regards,
Regina



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux