Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi Armin,

Armin Le Grand schrieb am 28.02.2024 um 20:20:
> Hi,
> 
> On 2/24/24 22:00, Regina Henschel wrote:
>> Hi Thorsten,
>>
>> Thorsten Behrens schrieb am 24.02.2024 um 17:29:
>>> Hi Regina,
>>>
>>> Regina Henschel wrote:
>>>> Unfortunately, our 3d engine does not support all needed features. Most
>>>> important problem is, that in our 3d engine only the first light is
>>>> specular.
>>>>
>>> I suspect that might be quick to add - Armin, what do you think?
>>
>> There is a member mbSpecular in class ImpSdr3DLightAttribute but 
>> ViewContactOfE3d::impCreateWithGivenPrimitive3DContainer() evaluates 
>> only the first light. But I don't know whether that is the correct 
>> area at all.
> I also would have to search, but can say that all 8 lights are the same. 
> I also remember that it is done for Chart since Ingrid did not want the 
> 1st light to be specular (our default), so 1st light is specular 
> switched off, 2nd is on AFAIR.

As far as I see she simply used 2nd light instead of 1st light.

  No idea where that would have to be done
> in import and if there is tooling for it, but it just needs to be set 
> correctly.

Mmh, I see D3DFoo properties for the shape how a material reacts on the 
light, but a light itself has only on/off, color and direction in the 
D3DFoo properties.

>>
>>>
>>>> Further problem with our 3d engine is, that we cannot render the
>>>> "Bevel" of MS Office. Not only the fancy ones, but the simple round
>>>> bevel is missing too. Our "Rounded edges" are in fact straight. In
>>>> MS Office you can use the bevel to create a sphere, for example.
>>>>
>>> Got it. Might also need some experimentation, such that we get the exact
>>> same look. Let me play with this features a little bit.
>>
>> I have attached a file with examples using "Bevel". Note that these 
>> are no "true" 3D-objects, but they are all custom shapes. We are far 
>> away from what MS Office can do with custom shapes.
> 
> Will have to compare with MSOffice, but sure we are far away - Sven did 
> implement by creating SdrShapes (WITHOUT being inserrted to 
> SdrPage/SdrModel, that caused many problems). Primitives were available, 
> but hey. It would be much better to create the visualization for 
> CustomShapes with Primitives directly (these get 'collected' from the 
> created SdrObjects currently). That would allow e.g. to just have a 
> primitive for the CustomShape that then gets decomposed to the needed 
> Primitives (also would think about not doing all of that all the time 
> and over the UNO API btw).
> 
> That would also be the way to do for 3D stuff - 3D primitives could just 
> create all that needed stuff, tesselating down to triangles (as is done 
> now for 'fat' 3D lines as already mentioned).
> 
> As long as CustomShape geometry processing uses SdrObjects I see no good 
> way to do more/the needed stuff, hence this is filed as Tender (since a 
> looong time). Unfortunately this is not simple for all cases - we also 
> have the FontWork to be adapted and quite some complicated stuff for 
> some CustomShapes, esp. the 3D stuff (creating 3D scenes with 3d 
> SdrObjects), but definitely worth it.

We should reserve some hours on the next LibreOffice conference and 
discuss especially 3D things. The problem is not only the extrusion of 
custom shapes, but also 3D scene for text and the new feature of MS 
Office to render 3D-Models (.glb files) including changes to camera and 
lighting properties.

> 
> Urgently needed change. I see NO way to do what you need here - with the 
> curent way of doing it you would have to create new SdrObjects (3D 
> Sdrobjects) that could do that - argh - or use that already mentioned 
> simple 3D SdrObjects that can represent 3D PolyPolygons, using just 
> trianges and doing the tesselation there. But why when that could be 
> done much smoother and simpler with 3D primitives.

Currently, the 3D-scene and the objects in it for an extruded custom 
shape are created in EnhancedCustomShape3d::Create3DObject().

> 
> Did i mention that that would also make things much easier? AFAIR for 
> some of those geometry creations SdrObjects get created and in 
> follow--up steps get used as geometry input and other SdrObjects get 
> created based on that - oh my...
>

So it is obvious, going that way is not feasible until the feature 
freeze of version 24.8. I will therefore try to emulate the lighting 
rendering as well as possible with the existing old properties.

Unfortunately, there are not only problems with the lighting. In 
addition to the bevel property already mentioned, the contour property 
is also missing. The material, handling of extrusion color, stroke and 
text are also different. And I haven't even looked at 3D-fontwork yet.

>>
>>>
>>>> The question is more whether to start that immediately or first
>>>> implement some ersatz lighting so that the shapes are approximately
>>>> as light as in MS Office. When you use the current import (in daily
>>>> build which has the 3d geometry) you can see, that our default
>>>> lighting gives bad results.
>>>>
>>> I guess the specular light & API changes for it are relatively
>>> straight-forward.
>>
>> Perhaps. A solution might be to give the 'dr3d:foo' attributes 
>> precedence over the 'extrusion-foo' attributes and use 'loext:foo' 
>> until they available in ODF.
>>
>> The 'extrusion-foo' attributes are available in API as properties in 
>> service EnhancedCustomShapeExtrusion.
>>
>> The use of the 'D3DFoo' properties is strange. They are not mentioned 
>> in an idl file. And trying to get the properties of an object in a 
>> scene in the Development Tools crashes LibreOffice.

The crash is tdf#159874 and Julien Nabet has committed a fix.

> Yes, Scene is 'picky' because of that old stuff that was just converted 
> to ODF and forced me to keep it alive. Old non-standard stuff from Joe...

The ODF specification and the API reflects the extrusion as it has been 
defined in VML, RTF and MSO binary format. Even if we implemented a new 
extrusion rendering that is more compatible with OOXML, we could not 
simple drop the old one as long as we provide filter for these formats. 
Those would have to be adapted too.

>>
>>  Then again, getting the code merged as-is would
>>> perhaps be quite satisfying, and I take it you would need some sort of
>>> quick emulation for that, since it looks just too bad?
>>
>> Yes, till August we need some sort of better lighting.

In the meantime I have learned how to interpret the light directions in 
the MS Office specification 
https://learn.microsoft.com/en-us/answers/questions/1551836/lightdirection-on-shape-with-3d-effect-is-rendered
Small steps, but I am making progress.

Kind regards,
Regina