Wednesday, August 20, 2014

3D models in Impress (LibreOffice 4.3)

The last LibreOffice release came with 3D model support in Impress. Now you can insert 3D models onto your slides in the open formats of glTF, COLLADA and KMZ. To do that go to Insert->Object->3D Model... in the menu hierarchy and after you selected a file you can see the model on your slide:

Impress with a duck model on the slide
Duck 3D model

Animated models

The inserted 3D models also can define some animations. In this case after insertion you can control the animation using the media toolbar's play/pause/stop buttons. During implementation we lean on the existing movie player feature, that's why 3D animations behave the same as movies. This similarity also exists inside the slideshow which means animations are also started as soon as the actual slide appears and the same custom animations are available to trigger play/pause/stop events.

Impress with a monster on the slide
Animated monster model

 

Hidden features of the model viewer window

This 3D model feature was implemented a bit late in the releasing process that can explain why some features of the viewer window does not appear noticeable on the UI. Hopefully the situation will be better on the next release, but until then let's see what are these features are.
First you should know that the viewer window is active only when the 3D model is "played" (push play button on the media toolbar or start the slideshow), even if the model actually doesn't have any animation to play. While the 3D model object is in stopped state, only a screen shot of the scene is displayed, which makes resizing and positioning easier in edit mode.

Changing camera position

So when the viewer window is active we can change the camera position to have a look at the model from different points of view. By default we are in walkthrough mode where we can handle the camera from a first-person perspective. We can move forward ('W'), backward ('S'), left ('A') and right ('D') using the keyboard and we can turn by click and drag.
You can see some pictures bellow about the walkthrough mode. However you can enter into the maze, but inside the maze navigation becomes hard. The perfect would be if we could walk in the maze like packman does but camera handling still needs some improvements.

Packman maze default view
Closer to the maze
Inside the maze
 
Next to the walkthrough mode there is an other one called orbit mode. Use 'M' key to switch between the two modes. In orbit mode the camera is moved on an orbit around the model, always looking at the model. Using the keyboard we can move the camera on this orbit northward ('W'), southward ('S'), westward ('A') and eastward ('D'), and we also can change the distance between the orbit and the center of the model ('E' and 'Q' keys). Click and drag event also moves the camera on this orbit, but from the user points of view this looks rather like the model is rotated around it's center.
On the next pictures you can see the different views after the model was rotated horizontally by mouse (in other words, camera was moved around the model horizontally):

Duck model, full face

Duck model, profile
Duck model, from behind

 

FPS rendering

We added an FPS (frame per second) rendering possibility to the viewer window, so the rendering performance can be measured easily. By default this feature is disabled. To enable it you can press 'F' key and you will see FPS number at the right-bottom corner of the viewer window.

Monster model with FPS

 

About the file formats

The main format is COLLADA, the other ones are closely related to it.
First KMZ is a zipped file format which can contain 3D models in COLLADA format. So not all KMZ files can be loaded by LibreOffice, it's assumed that the given KMZ format contains only one 3D model. The main advantage of supporting KMZ format is the huge source of free 3D models on the 3D warehouse site. On this site almost all models are available in KMZ format.
The glTF format is a really new format, actually it has only a draft specification. The main purpose of the format is the better performance. It is designed to make loading and rendering of the models faster, with using such structures which are closer to the OpenGL language. It's not an independent file format but rather a runtime form of COLLADA. So in general glTF models are generated from COLLADA files and creating/editing of the 3D models is done in COLLADA format.
Since glTF is desgined to be faster, LibreOffice stores all 3D models in this form both in runtime and in the ODP file. When a KMZ or a COLLADA file is inserted into Impress, the file is converted to glTF and rendering comes just after that.

Some limitations you should aware of

First of all it's good to know that Impress uses OpenGL 3.0 for rendering of these 3D models. If your graphic card doesn't support it then only a question mark will be displayed on the screen, but the model is there, so if you save your presentation and move it to a capable computer then it will appear.
Other limitations come from that glTF is a draft format and collada2gltf tool (used for COLLADA->glTF conversion) is also unstable. So don't surprise if some of the KMZ files downloaded from Warehouse are not rendered well.
By now this feature is available only for Windows and Linux.

Who stands behind the feature

3D model support came alive as a result of the cooperation of Collabora, AMD and MCW.
First of all AMD founded our work and was coming up with new ideas about the feature.
Secondly a developer group from MCW was working on the parser/rendering code of the glTF format. To make our cooperation with MCW more misunderstanding tolerant we set up a wall between LibreOffice code and glTF parser code with defining an API. Later, from that separation born an open source glTF rendering library called libglTF. By now libglTF is still developed closely to LibreOffice.
Last but not least we at Collabora have done the integration into LibreOffice. First Markus Mohrard was working on LibreOffice OpenGL code in general, made it better/more fresh and generalized it allowing to use the same code for all OpenGL based  features: OpenGL transitions, OpenGL charts and glTF models. Jan Holesovsky (Kendy) was the manager of the project, making plans, participating in brain storming and having great ideas. Matus Kukan helped us with integrating COLLADA related libraries into LibreOffice (for COLLADA->glTF conversion).
Finally I implemented embedding of glTF models into Impress by setting together the pieces (plans from Kendy, generic OpenGL pieces from Markus, COLLADA conversion from Matus and glTF rendering from MCW).

Monday, September 30, 2013

GSoC 2013 - Character border

Character border (fdo#35155)

In this summer I participated in Google Summer of Code and implemented border on the character level. So in the next 4.2 version of LibreOffice users will be able to set border around a run of characters.

Two example of character border. Above there is a drop cap letter with double border and blue background. Under there are two words with a blue border around it plus a box-shadow on the top-right side of the border.

The character border can be specified as a direct formatting via Format -> Character -> Borders tab and it also can be the part of a character style (e.g. Format -> Styles and Formatting -> Character Style). One special case of the latter is drop caps character style.

Drop Caps

While I was working with character border and I was testing whether it works in all cases I realized that Drop Caps has some bugs which keep me from adding my new feature. So I have to solve them before I able to keep on my original project:

1. User defined background was shifted upward
Two parts of the picture shows the background painting before the bug fix and after that. Before the default gray background was hanging out from behind the user defined yellow background. The after part shows that after fixing the bug only the user defined yellow background is painted.
Since border is drawn at the edges of the background, it was also drawn at the wrong place.

2. Changing line height
A drop caps with the deafult gray background and a red arrow showing that the first line of the paragraph next to the drop cap has bigger height as it is expected.
Height of the first line was changing unexpectedly when the drop cap letter's original height was bigger than the height of the following characters. Original means the height which it would have if it wasn't a drop cap. By now this original height is ignored during height calculation of the first line.
Since border rendering increase this height with the border width, line height also increased with this width.

3. ODF import loses drop caps character style (fdo#43807)
It also loses the border including by this character style.

Border merge

The implementation of character attributes and the specification of ODF file format make it necessary to add automatic border merge functionality. Border merge means that if two text ranges have equal border (same line, padding and shadow) they will be rendered inside the same border.

Above there is a text with two bordered text range with one Q letter between them. After this Q letter is removed the two border text range are merged and so are rendered within the same border.

Border merge also means background merge, since this is a general concept to draw border at the edges of the background.
When there are letters with different sizes and they have background then this background's height will depend from the height of the text. So letters with different size will have different hight background. But if this letters are merged to one border group then they will have a coherent background.

File formats

List of file formats to which/from which Writer exports/imports character border:
ODT, HTML, DOC, DOCX, RTF

Monday, June 17, 2013

LIMIT improvements in LibreOffice 4.1

Some new things get into this version of LO.

1. The primary improvement is adding a combobox to the design view and so not needed to use SQL view to limit the number of resulting rows. This new edit is get place on the query design toolbar and in the Query Properties dialog (Edit -> Query Properties).

Place of the new toolbar item is on the rightmost side of the query toolbar.
New toolbar item to limit a query result
in query design view.

Query properties dialog has the same box as the query design toolbar. These two box are in sync.
New dialog to add query properties like limit and distinct values.

2. LO uses HSQLDB (version 1.8.0) as an embedded\default database so this is an commonly used driver for Base. However it has a bug which lead to an exception when user intend to run a query like "SELECT * FROM table LIMIT n". The problem is HSQLDB's parser does not handle "LIMIT" as an keyword and so in this case "LIMIT" parsed as a table alias and the following number as an unexpected token. Inside LO this bug is fixed by now.

An error box saying the number after the LIMIT is unexpected.
In older versions, HSQLDB throws an exception when
use LIMIT directly after from clause.

The rows are listed with expected number.
LO 4.1 doesn't throw the HSQLDB's exception and return
with the expected result.

Of course it also means LIMIT keyword can't use as a table alias anymore in LO as it was used before. These usage is stand only when use "Run SQL command directly" option. (LO has an own parser which notice that LIMIT is a keyword and so can't be a table alias, but with this option this syntax check can be avoided)

Limit used as an table alias in SQL statement and Base return with all elements of the table without problem.
Before, user was able to use LIMIT as a table alias.

An error box is opened which say that LIMIT is unexpected token.
LO 4.1 throws an exception, when use LIMIT as a name
(get from fixed HSQLDB)

3. This is my favorite. In SQL mode, in the SQL edit the LIMIT keyword was highlighted wrong as a single name (green colour) and not as a keyword (blue colour). The origin of this problem may be the same as in case of HSQLDB's bug. The LIMIT keyword got into the code later as other keywords and it was missed to add all of places where a keyword has to appear.

In the SQL edit the LIMIT word has green color.
Before, the LIMIT keyword was highlighted
with green color like a simple name.

In the SQL edit the LIMIT word has blue color just as the oder keywords like SELECT, FROM and so on.
In LO 4.1, the LIMIT keyword has the same highlighting as
other keywords (blue character color).