Re: Problems with lighting of extruded custom-shapes

[Miklos Vajna]

Hi Regina,

On Fri, Jan 07, 2022 at 07:22:19PM +0100, Regina Henschel 
 wrote:
> > I assume doing that would be the scope of
> > .
> > 
> 
> Yes, but the Budget2022 proposal has import of text in addition, which can
> be included in the object rotation in MSO.
> 
> However, the suggestion text is not clear. It can be interpreted as using
> "SdrObjCustomShape" or as using "E3dScene".

I think the proposal is to add MSO-compatible 3D effects, so extend
SdrObjCustomShape with properties that allow importing and rendering
these 3D properties.

My understanding is that E3dScene is nice, but it doesn't preserve
editable text, and in general not a 1:1 match to MSO's 3D approach,
which is just a set of additional properties on (2D) shapes.

> The "E3dScene" has no corresponding shape type in OOXML and not in binary MS
> format.

Good, that matches the above. :-)

> MS goes a different way and has introduced "3D Model". That is a GLB media
> file, which is inserted as w:graphic and uses the object rotation and camera
> from OOXML.

I assume those 3d models are less interesting to you. It's somewhat
ironic that we had GLTF models and it was removed as nobody bothered to
keep the feature... :-)

> I'll write a bug report for RTF import.

Thanks, got it. I'm interested to take a look once you're happy with the
binary filters (so I can use that behavior as reference).

Regards,

Miklos

Re: Problems with lighting of extruded custom-shapes

[Regina Henschel]

Hi Miklos,

I have put it into code now, see 
https://gerrit.libreoffice.org/c/core/+/128449

That makes it perhaps easier to discuss the problems.

My changes give good results for import of MS binary formats, especially 
if the user has chosen to illuminate the object from front or if the 
user had set surface 'Metal' in the UI of MS Office. I can sent you 
files in MS binary format for testing. But I think you will already have 
got lots of those files.


The code is WIP and the unit tests from my previous commit will break. 
But the code itself builds here on Windows, so you should be able to 
build a working version for testing.


Kind regards,
Regina

Re: Problems with lighting of extruded custom-shapes

[Regina Henschel]

Hi all,

(Hi Miklos, I repeat here my answer to you for the list, because CC 
didn't work because the attachment was too large.)


Miklos Vajna schrieb am 07.01.2022 um 14:30:

Hi Regina,

On Thu, Jan 06, 2022 at 10:33:54PM +0100, Regina Henschel 
 wrote:

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.


Is it correct that these are not taken into account while rendering at
the moment?


Yes.

An extruded shape is imported without extrusion, a "3D Model" is shown 
with its fallback image, an extruded text (new kind of WordArt) is not 
even imported as Fontwork shape but as text box.




I assume doing that would be the scope of
.



Yes, but the Budget2022 proposal has import of text in addition, which 
can be included in the object rotation in MSO.


However, the suggestion text is not clear. It can be interpreted as 
using "SdrObjCustomShape" or as using "E3dScene".



But if that's true, then we don't really map LibreOffice's 3D objects to
MSO formats in general, am I right?


The "E3dScene" has no corresponding shape type in OOXML and not in 
binary MS format. So those objects are totally lost in export to OOXML 
and replaced with image in export to binary MS format.
MS goes a different way and has introduced "3D Model". That is a GLB 
media file, which is inserted as w:graphic and uses the object rotation 
and camera from OOXML.


An extruded "SdrObjCustomShape" both as shape and as Fontwork is 
exported to OOXML without extrusion.


Exchange in RTF doesn't work too.

Only exchange as binary MS format works beside the shortcomings on which 
I currently work.


So exchange of any kind of 3D object with MS Office is in a very bad state.




Fontwork is affected too, because it is only a special mode of a
custom-shape >

So would that mean fontwork is the only case where we currently import a
shape from MSO formats and that results in a 3D object on our side?


No, Fontwork/Wordart in 3D mode doesn't work too. Same as with shapes, 
only binary MS format works.




I hope once these are clear, we can discuss the individual properties
more easily. :-)


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.


Somewhat related, if you have some RTF document where these properties
are not imported, but the DOC version of it is imported correctly, I
would be interested to look at that -- could you please file a bug and
CC me?


No extrusion properties are imported from an RTF document. They all end 
up in
859  SAL_INFO("writerfilter", "TODO handle shape property '" 
<< rProperty.first << "':'"

860 << rProperty.second << "'");
in writerfilter/source/rtftok/rtfsdrimport.cxx

I'll write a bug report for RTF import.

The import of the DOC version works in principle, but has wrong units 
for "Shininess" and for "Specularity" and needs to explicitly set 
default values if they are different from ODF defaults. I'll fix that 
together with the rendering problems.


Kind regards,
Regina

Re: Problems with lighting of extruded custom-shapes

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 07.01.2022 um 14:30:


Somewhat related, if you have some RTF document where these properties
are not imported, but the DOC version of it is imported correctly, I
would be interested to look at that -- could you please file a bug and
CC me?


Bug for RTF import is
https://bugs.documentfoundation.org/show_bug.cgi?id=146644

Kind regards,
Regina

Re: Problems with lighting of extruded custom-shapes

[Miklos Vajna]

Hi Regina,

On Thu, Jan 06, 2022 at 10:33:54PM +0100, Regina Henschel 
 wrote:
> 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.

Is it correct that these are not taken into account while rendering at
the moment?

I assume doing that would be the scope of
.

But if that's true, then we don't really map LibreOffice's 3D objects to
MSO formats in general, am I right?

> Fontwork is affected too, because it is only a special mode of a
> custom-shape.

So would that mean fontwork is the only case where we currently import a
shape from MSO formats and that results in a 3D object on our side?

I hope once these are clear, we can discuss the individual properties
more easily. :-)

> 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.

Somewhat related, if you have some RTF document where these properties
are not imported, but the DOC version of it is imported correctly, I
would be interested to look at that -- could you please file a bug and
CC me?

Thanks,

Miklos

Problems with lighting of extruded custom-shapes

[Regina Henschel]

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 8/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