Import of lighting from MS Office for extruded shapes

[Armin Le Grand]

Hi,

On 2/24/24 16:56, Regina Henschel wrote:
> Hi Thorsten,
>
> Thorsten Behrens schrieb am 22.02.2024 um 21:04:
>> Hi Regina,
>>
>> Regina Henschel wrote:
>>> Any ideas/wishes for a reasonably usable import?
>>>
>> Our 3d engine already supports all this FWICT (I see e.g.
>> SDRATTR_3DSCENE_LIGHTCOLOR_1 - 8) - so why not extend ODF here, when
>> it's obviously lacking?
>
> Unfortunately, our 3d engine does not support all needed features.
It does. We need to separate by the parts of the 3D render hierarchy. 
All 3D renderers do rasterconvert triangles, so do we. Q is how the 
tesselation in the geometry preparations does things, e.g. we create 
'tubes' in 3D for fat lines, etc..
> Most important problem is, that in our 3d engine only the first light 
> is specular. We need three specular lights for MS Office light rigs. 
> "Specular" means, that the light produces a bright spot on the shape.
You can just switch it on for every of the 8 lamps, they are all the 
same. More important is that you need 'phong' rendering to make it 
'visible' in the raster conversion. I repeat that we use the standard 
model for 3D stuff, refer to the book 'Computer Graphics' 
Foley/VanDam/Feiner/Hughes. Of course today's (esp. HW-stuff) is 
'advanced' but those basics always are the starting point.
>
> 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.
I would need an example for this, but this is of class 'tesselation' AKA 
geometry creation AKA decomposition since we have primitives in 3D, too. 
All this needs to be decomposed to triangles (even when in-between you 
might use stuff like 'bezier patches' in 3D or whatever).
>
> Nevertheless, extending ODF is likely needed anyway. That would 
> include extending our API because the import goes via API properties. 
> 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.

As said, we can render that lighting, Q is only how to get it through 
the levels/hierarchy. We need to separate:

(1) Renderer and capabilities

(2) Geometry creation/decomposition (3D primitives)

(3) Model (SdrObjects and 3DScene - sigh...)

we can anytime adapt (2), e.g. there IS a simple primitive for ANY kind 
of planar surface if you really need to define the geometry yourself. 
AFAIR even in (3) we have one 3D SdrObject just holding the data for a 
3D plane/Polygon with normal definitions & texture coordinates.

The only thing that might be problematic is the OLD camera definition in 
SdrObject/ODF level - THAT was just im/exported by someone and is not 
fully fulfilling that standard - I moved it do do so in a compatible 
way, but we are not completely free here until we do better in ODF.

Regards,

Armin

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