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