Import of lighting from MS Office for extruded shapes

[Armin Le Grand]

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

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.

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

>
>>
>>> 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.
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...
>
>  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.
>
> Kind regards,
> Regina
>
-- 
Armin Le Grand

Senior Software Engineer FLOSS
–––
allotropia software GmbH
Versmannstr. 4
20457 Hamburg
Germany
–––
armin.le.grand.extern at allotropia.de
https://www.allotropia.de
–––
Registered office: Hamburg, Germany
Registration court Hamburg, HRB 165405
Managing director: Thorsten Behrens
VAT-ID: DE 335606919
---