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 <rb.henschel at t-online.de> 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
> <https://wiki.documentfoundation.org/Development/Budget2022#3D_rotation_of_Impress_shapes>.
>

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