Re: Import of lighting from MS Office for extruded shapes
Hi Regina, On Tue, Mar 12, 2024 at 03:10:04PM +0100, Regina Henschel wrote: > I have finished my patch in https://gerrit.libreoffice.org/c/core/+/164510, > including some unit tests. It would be nice if someone has some time to > review it. If you will do it, please add you their or notify my here. If no > one wants to look at it, I'll commit it as it is. This sounds like a good plan, you're slowly turning into the world expert on extruded shapes. :-) Regards, Miklos
Re: Import of lighting from MS Office for extruded shapes
Hi all, I have finished my patch in https://gerrit.libreoffice.org/c/core/+/164510, including some unit tests. It would be nice if someone has some time to review it. If you will do it, please add you their or notify my here. If no one wants to look at it, I'll commit it as it is. Kind regards, Regina
Re: Import of lighting from MS Office for extruded shapes
Hi all, Regina Henschel schrieb am 22.02.2024 um 19:47: Hi all, I have started work on import of lighting. But there are several problems which make it impossible to get a 1:1 match to our capabilities. [..] Any ideas/wishes for a reasonably usable import? I have uploaded the current state to Gerrit https://gerrit.libreoffice.org/c/core/+/164510 Please notify me, if there is something which I should change. The meaning of 'Specular' and 'Diffuse' in the specification of MS Office is not clear. I posted a question to the forum https://learn.microsoft.com/en-us/answers/questions/1608333/what-is-specular-and-diffuse-in-the-lightrig-table Besides the mentioned principle problems, this is missing: MS Office uses 'Gouraud' as default render mode. That is currently not used but the default 'Flat' mode. In some cases MSO uses Phong render mode. The information about that is contained in the material presets and those are not yet evaluated. Kind regards, Regina
Re: Import of lighting from MS Office for extruded shapes
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
Re: Import of lighting from MS Office for extruded shapes
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.ext...@allotropia.de https://www.allotropia.de ––– Registered office: Hamburg, Germany Registration court Hamburg, HRB 165405 Managing director: Thorsten Behrens VAT-ID: DE 335606919 ---
Re: Import of lighting from MS Office for extruded shapes
Hi Armin, Armin Le Grand schrieb am 28.02.2024 um 11:16: 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, The previous mail from me to this topic has an attachment with bevel examples. You should have got that mail directly. Kind regards Regina
Re: Import of lighting from MS Office for extruded shapes
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.ext...@allotropia.de https://www.allotropia.de ––– Registered office: Hamburg, Germany Registration court Hamburg, HRB 165405 Managing director: Thorsten Behrens VAT-ID: DE 335606919 ---
Re: Import of lighting from MS Office for extruded shapes
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. 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. 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. 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 Bevel examples.pptx Description: MS-Powerpoint 2007 presentation
Re: Import of lighting from MS Office for extruded shapes
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? > 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. > 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. 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? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: Import of lighting from MS Office for extruded shapes
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. 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. 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. 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. Kind regards, Regina
Re: Import of lighting from MS Office for extruded shapes
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? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: Import of lighting from MS Office for extruded shapes
Hi Regina, On Thu, Feb 22, 2024 at 07:47:42PM +0100, Regina Henschel wrote: > I have started work on import of lighting. But there are several problems > which make it impossible to get a 1:1 match to our capabilities. Just an idea: would it make sense to split this to two steps: 1) Just import what is possible to represent with our model. 2) The more involved work to extend our model/rendering/etc. And 1) alone would be already useful, and it would be a good starting point for 2). Would that make sense? Regards, Miklos
Import of lighting from MS Office for extruded shapes
Hi all, I have started work on import of lighting. But there are several problems which make it impossible to get a 1:1 match to our capabilities. Some of these problems are: (1) A lightRig in MS Office uses up to 4 lights. But ODF and our API have only two lights. (2) The MS Office lightRigs 'chilly', 'flat', 'freezing', 'morning', 'sunrise' and 'sunset' use colored light. ODF and our API have no color for a light but only an intensity (='level'), which means our lights are Gray. (3) There are lightRigs in MS Office with more than one specular light. Our 3D rendering engine has maximal one specular light. A 'specular' light makes a bright spot on the shape in case the shape material is 'shiny'. (4) Our dialog '3D-settings' fits to shape extrusion of binary MS Office and the 'legacy*' lightRigs. But these 'legacy*' lightRigs are not available in the UI of modern MS Office. So we import lightRigs for which the user has no UI. Any ideas/wishes for a reasonably usable import? Kind regards, Regina
