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@xxxxxxxxxxxxx
https://www.allotropia.de
–––
Registered office: Hamburg, Germany
Registration court Hamburg, HRB 165405
Managing director: Thorsten Behrens
VAT-ID: DE 335606919
---
