Qt and Direct3D 12 – First Encounter

The landscape of graphics APIs is changing. Qt Quick 2, released with Qt 5.0 in 2012, was betting heavily on OpenGL and OpenGL ES 2.0. There have been changes and improvements since then – the Qt Quick 2D Renderer was introduced, experiments with software rasterizers were made, and enablers for newer OpenGL versions got added all over the Qt graphics stack. However, as Lars mentioned in his Qt World Summit 2015 keynote, the situation is changing: new, low-level, more efficient APIs like Vulkan, Metal and Direct3D 12 are about to become widely available. Some of these are tied to certain platforms, making them the best choice when targeting the platform in question, while others are expected to be present on a wider variety of systems. At the same time betting solely on a complex, accelerated API is not always the best choice: traditional, desktop user interfaces running on older hardware are sometimes better served with plain old CPU-based rendering.

Therefore, unsurprisingly enough, one of the research areas for upcoming Qt versions is making the graphics stack, and in particular, Qt Quick, more flexible, with support for different graphics APIs as well as software rendering.

Such research work often leads to useful side effects: this post is about one of these, a simple Qt module enabling easy integration of Direct3D 12 rendering into a standalone Qt window – or alternatively QWidget-based applications – and making it easier to get started and experiment with modern D3D techniques while continuing to enjoy the familiar APIs, tools, and development environment Qt and its ecosystem offer.

What it is

The QtD3D12Window module, living in a qt-labs repository, is a Qt 5.6 module providing a QD3D12Window class similar to QOpenGLWindow, a handy qmake rule for offline HLSL shader compilation via fxc, and a comprehensive set of examples for a number of basic use cases (inspired by Microsoft’s own Hello World samples).

What it is not

Before going further, let’s reiterate what this module is not: it is not a way to run existing Qt applications on Direct3D (that is exactly what ANGLE provides when it comes to D3D9 and 11), nor does it support Qt Quick in any way. It is also not something that will get added to Qt in its current form, and it is not a complete engine or framework of any kind (the interface QD3D12Window offers is likely insufficient for more complex, multi-threaded approaches).

Window

The first step for integrating custom rendering code using a new graphics API is to make the rendering target a QWindow’s underlying native window. Currently OpenGL is the only choice and it is deeply integrated into Qt both internally (QPA interfaces, platform plugins) and externally (public APIs, see the QOpenGL classes in QtGui for instance). This is expected to change in the future, but for now, for our standalone D3D experiment, we will just do everything on our own. Qt’s windows platform plugin makes it easy to obtain the native window handle (HWND) as that is exactly what QWindow::winId() returns in Qt applications running on Windows. We can then use DXGI to enumerate the available adapters, pick either a hardware one or WARP, and create a swap chain. QD3D12Window handles all this, with defaults that are good enough for the typical basic applications.

Speaking of DXGI, this marks our first foray into graphics adapter and device management: while with OpenGL and its usual windowing system interfaces such capabilities are limited, other APIs (especially the ones tied to platforms with a suitable driver model) may offer a lot more when it comes to discovering graphics adapters and managing device changes, removals and resets during the lifetime of the application. Such functionality, on platforms and APIs where available, is expected to get more focus in Qt in the future.

While implementing QD3D12Window, it turned out there was no need to do much generic plumbing – thanks to the way QOpenGLWindow and QRasterWindow had been introduced back in Qt 5.4: the common base class QPaintDeviceWindow (somewhat misleading in the D3D case as our window here is not suitable for QPainter-based painting) provides all the necessary infrastructure so subclasses can focus on the graphics API specifics while getting the basic, consistent Qt functionality – like update() – out of the box. This is good news since it allows easy experimenting with other APIs as well in the future (QMetalWindow, QVulkanWindow, you name it).

Class

QD3D12Window mirrors QOpenGLWindow which in turn is based on QOpenGLWidget/QGLWidget’s well-known initializeGL – resizeGL – paintGL interface, with GL becoming D3D, naturally. There are two new functions subclasses may reimplement: releaseD3D and afterPresent. The latter is invoked every time after issuing a Present call: most simple applications will wait for the GPU via a fence here. The former is used to make applications able to survive device removals: when the graphics device becomes unavailable, this function is invoked and is expected to release all resources it has created during initialize/resize/paint. QD3D12Window will then then take care of starting over and invoking initializeD3D again. This way the application can remain functional even when a driver update or a timeout in shader execution occurs.

The best is probably to dive straight into the examples, looking at hellotriangle for instance shows that if you haved used QOpenGLWindow or QOpenGLWidget before, QD3D12Window will present no unexpected surprises either.

Widgets

So now we can have a top-level window with nothing but our awesome D3D12-rendered content in it. This is excellent but what about having some traditional user interface controls in there? For now, the approach that is usable with QD3D12Window is to make it a native child window via QWidget::createWindowContainer(). This comes with the usual limitations so be sure to read the documentation first. Nonetheless it will work fine for most simple purposes.

hellooffscreen, one of the QD3D12Window examples

Shaders

The handling of shader code and compilation is another very interesting topic. With OpenGL, Qt and Qt Quick bet on runtime compilation due to that being the only universally available solution not involving vendor and platform specifics. With other graphics APIs in the future, it is expected that Qt will focus more on offline compilation, integrating it into the build system as much as possible. Besides the obvious performance benefits, this drastically improves the development workflow as well: getting a proper compiler error right when hitting Ctrl+B in Qt Creator can easily feel infinitely superior to the “old” way of browsing the debug output while running the application.

The QtD3D12Window module comes with a simple qmake rule that allows invoking fxc.exe during build time. All the examples use this to generate header files where the compiled bytecode is provided as a plain char array. Take a look at the the .pro file for one of them and the shader setup for the pipeline state. Simple and easy, isn’t it?

All this is not completely new to Qt: the bundled ANGLE in qtbase performs shader compilation in the same manner. However, that is hidden to and not usable by application-level D3D code, while the hlsl.prf file here can be copied over to the Qt SDK’s mkspecs/features folder, making it available to any Qt application.

Graphics Debugging

QD3D12Window automatically enables the D3D12 debug layer. This is extremely useful in practice as many of the common mistakes made while getting started with D3D12 result in human readable, verbose and actually helpful debug messages. However, you may want to disable this when doing performance testing or overhead comparison.

Another helpful tool is the graphics debugger included in Visual Studio. One way to launch this for Qt apps is doing devenv /debugexe qtapplication.exe from a developer command prompt and hitting Alt+F5. (alternatively, generating Visual Studio project files with qmake -tp vc may work too) This proved to be quite useful while developing even our simple examples – for instance the ability to inspect graphics resources and see if we managed to correctly generate all mipmap levels is immensely helpful.

Examples

As mentioned before, the module comes with a set of examples that cover the basics and may be useful to anyone getting started with D3D12 development. See the readme for an overview.

That’s it for now, hope you find our little labs module useful. Happy hacking!

The post Qt and Direct3D 12 – First Encounter appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1SkPVcs

Using Qt 3D to visualize music

As the development of the Qt 3D module is proceeding we wanted to give it a try and test how one could visualize music using the module. The result of this experiment was a new example, Audio Visualizer Example, to the Qt 3D module.

Audio Visualizer Example playing Lost Neon Sun by Tiltshifted

The example shows how you can use Qt 3D rendering with Qt Quick elements. The 3D content is rendered using the Scene3D type. The bars are objects in NodeInstantiator and they are animated to visualize the magnitude of the music played. On top of the scene we’ve placed buttons to pause/play and to stop the music. These buttons are Qt Quick elements. The music is played using MediaPlayer provided with Qt Multimedia module.

In the example there’s a curve shaped 3D entity to show the progress based on the duration of the played track. There’s also a prism 3D entity to show the title of the example and the song. The prism shows the title of the song while the song is played and the title of the example becomes visible when the playing is stopped. The titles are placed on different edges of the prism and the angle of the prism is animated once the title needs to be changed.

If you want to give the example a try you can find it from codereview.qt-project.org under examples\qt3d\audio-visualizer-qml. We are aware that there are still some improvements that could be made to the backend performance to make the animation of the bars smoother, but as Qt 3D is Technology Preview in the upcoming Qt 5.6 release these improvements are more than likely.

This example was created to give some ideas of what you can achieve using Qt 3D. We hope you like it!

The post Using Qt 3D to visualize music appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1TnoGPd

Iori Ayane – Qt Champion

We start the introduction of the 2015 Qt Champions with Iori Ayane who is an active participant in the Japanese Qt scene.

Qt is big in Japan, Iori is the second Japanese Qt Champion in two years. There is a really impressive community of Qt users in Japan with regular meetups and activities.

Iori first saw Qt at a workshop in Nagoya in 2011 held by Suzuki-san (Qt Champion 2014).

The thing that really resonated for Iori was Qt Quick, which he immediately started using after the workshop and hasn’t stopped since.

Among the projects he has made are:

• a Twitter client, that he used as an introduction project for himself. It started off as a Windows Mobile project, but worked on multiple platforms including all desktop platforms, Android and Meego (Nokia N9)
• A space invaders style space shooter, that was coded in under a week. (The graphics are fan art for Madoka ☆ Magica, a Japanese anime)
• An Android custom theme viewer application, used for viewing Android custom themes on the PC while you create them. It works with a Japanese custom Android ROM.
• A tool with which you can play web games and easily share screenshots from them to twitter. It’s a web browser with tools specifically to take screenshots and share them.

While Iori has coded a lot, the thing that sets him really apart is that he has written several books on Qt in Japanese. This also started much like his coding with Qt Quick. After coding with Qt Quick for a while Iori felt that Qt Quick is such a wonderful technology that it should be more widely known. However there were no books in Japanese at the time. Iori had written about Qt Quick on his blog, but it felt limited, so he wrote an introduction to Qt Quick in Japanese and got it published with the help of friends.

Iori presenting Lars Knoll with his books at Qt Contributors’ Summit 2015.

On top of all that Iori has also been translating the Qt Installer Framework to Japanese and last year he started committing patches to Qt based on his translation. As a side project from the Qt Installer Framework work, Iori has written a book on the Framework and it has also been published.

The thing that has really impressed Iori in the Qt Community is that everyone is accepted as part of the community. The Japanese Qt community has grown as more people know about Qt and they have regular meetups and workshops in several locations.

Iori himself started with just making small hobby programs and has now made several books and patches to Qt. He likes to tell people about Qt and how easy it is to get started with Qt.

Again, congratulations to Iori on the title of Qt Champion 2015!

The post Iori Ayane – Qt Champion appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1SamOu6

High-DPI Support in Qt 5.6

Qt 5.6 brings improved high-DPI support, in the form of better support for the devicePixelRatio scaling mode. In this blog we’ll look at how to configure and enable it, from the perspective of a Qt application user and a Qt application developer.

Unscaled sammegame vs scaled samegame

Developing applications won’t be covered in depth now, but has to some extent been covered earlier. The short story is that applications generally benefit from this high-DPI mode even without modifications.

This high-DPI mode is a virtualization mode, where there is not necessarily a 1:1 correspondence between a unit in the QWidget/Quick item coordinate system and a pixel on screen. One “unit” then has constant visual size across systems with different display densities, and actual screen pixel density is to a large degree hidden from the application.

Dots Per Inch (DPI) is the traditional measurement for display density, where a standard density display has a DPI value of 72 or 96. Qt as always scaled fonts automatically according to the system DPI, and then the application code was responsible for scaling hardcoded layout sizes. The Qt styles would to a certain degree adapt to the font size. The devicePixelRatio mode is different in two ways: First, the display density is expressed as a scale factor — the devicePixelRatio in Qt — ranging from 1 to n. Second, the scale factor is applied lower in the stack (on the Apple platforms at the OS level), and is less directly used in application code.

There is often a fixed relation between DPI and scale factors on a given platform:

Android DPI and scale factors

class	DPI	Scale Factor
ldpi	120	0.7
mdpi	160	1
hdpi	240	1.5
xhdpi	320	2.0
xxhdpi	480	3.0
xxxhdpi	640	4.0

From stackoverflow. Quiz: Why is 1x 160 DPI on Android, compared to ~90 on desktop?

Demonstrating rendering at display densities on a blog is difficult. What we can do instead change the devicePixelRatio Qt sees while keeping the display scale factor constant. This results in larger visual sizes at higher devicePixelRatios:

The Qt Labs Controls SpinBox at various scale factors, including the unsupported 1.5x.

<strong<Enabling high-DPI support: Qt needs to be provided with a scale factor for all displays on the system. There are several possible sources for the scale factors: The values can be provided directly by the OS, Qt can compute them based on traditional display metrics provided by the operating system (such as the DPI value), or the user or developer can provide them directly. The mechanisms for setting and enabling the sources are environment variables and application attributes.

Historical Sidebar:Qt 5.4 and Qt 5.5 on X11 and Windows supports setting the devicePixelRatio with QT_DEVICE_PIXEL_RATIO=n (integer only). This setter has now been deprecated and replaced with several others, as described below.

Let’s look at three different cases:

Case I: The operating implements high-DPI scaling and provides a scale factor.

This is the situation for the Apple platforms – the OS enables the high-dpi mode, and Qt and the application come along for the ride.

This is also the case for Qt on Wayland when the Wayland display server is configured with scaling enabled:

./weston --scale 2

For the experimentally inclined, Qt for Native Client also gets a scale factor set when browser zoom is activated.

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:

QT_AUTO_SCREEN_SCALE_FACTOR=1 ./myApp

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_WIDTH, QT_QPA_EGLFS_HEIGHT and the display pixel size.

Enabling can also be vetoed, either by environment variable or by the application:

QT_AUTO_SCREEN_SCALE_FACTOR=0 ./myApp

QGuiApplication::setAttribute(Qt::AA_DisableHighDpiScaling)

The use-cases for vetoing are “I’m not getting correct DPI values from my displays” and “my application really needs to work in display pixels”. Note that this vetoing only disables “Case II” scaling: Qt can of course not change how the OS works, and manual set scale factors (below) are also kept as as a separate case.

Case III: Setting a scale factor manually.
Supported Cross-platform.

QT_SCREEN_SCALE_FACTORS=1;2;1 ./myApp

Sets the scale factors for all screens. Screen order is QApplication::screens() order. This setter assumes that text has already been properly scaled for the display, through the DPI setting, and then scales the rest of the user interface to match.

QT_SCALE_FACTOR=2 ./myApp

Sets a global scale factor for the entire application, scaling everything uniformly. This final option is useful for development and testing, and allows you to test any scale factor on any hardware. It can also be useful for some embedded scenarios – for example if you are targeting a single display type with a full-screen application: tweak the scale factor until the UI has the correct visual size.

The finer points:

Q: What happens if I use more than one of these setters?
A: The scale factors are multiplicative. Setting QT_SCALE_FACTOR=2 on a 2x device gives an effective devicePixelRatio of 4.

Q: Are non-integer scale factors supported?
A: Qt uses qreal in the API, and will allow setting non-integer scale factors via QT_SCALE_FACTOR. However, Qt does not guarantee that graphics and styles will be glitch-free in that case. Styles may break first: the fusion style is generally most scalable. The Qt platform plugins round the reported scale factors to the nearest integer.

Q: Could a scale factor of 0.5 allow me to work in device pixels on a 2x device?
A: That’s uncharted waters, but a possibility.

Availability
The new High-DPI functionality is part of Qt 5.6 release. To try it out, please check out the Qt 5.6 Beta.

The post High-DPI Support in Qt 5.6 appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1nMvI49

Notification for all Qt Cloud Services users

Over a year ago we launched Qt Cloud Services, which includes Managed Runtime Services, Managed Application Runtime (MAR), Managed Database (MDB) and Engin.io. Since then we have received great feedback and seen some amazing cloud-connected applications published on the platform. However, the take-up of our services has not been what we had hoped. Consequently, we are currently looking into ramping down Qt Cloud Services. Meantime we will be discontinuing further sales.

We value our customer relationships and therefore believe in providing you as much transparency on this as early as possible. The service will be up and running at least through H1 2016. You will receive at the minimum 3 months’ notice prior to any changes.

Again, we value your business and welcome you to contact us to discuss your particular concerns and questions via info@qtcloudservices.com.

 

Best regards,

The Qt Cloud Services Team

The post Notification for all Qt Cloud Services users appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1KBpcBY

Qt Charts 2.1.0 Release

We’re happy to announce that the upcoming Qt 5.6.0 release includes Qt Charts 2.1.0 add-on. This Qt Charts release contains new features and bug fixes based on customer requests.

A short introduction of the module to those of you new to it: Qt Charts is a module that provides a set of easy to use chart components. Different chart types that are available: Line, Spline, Area, Scatter, Bar, Pie, Polar and Box-and-Whiskers Chart.

Example of some chart types available

More information, including examples of Qt Charts usage, can be found from the documentation.

As announced recently, the Qt Add-ons licensing will be changed so that the Qt Charts module becomes available under both GPLv3 and commercial license terms. The source code for the module has already been pushed to codereview.qt-project.org. With Qt 5.7 release the packages will include a pre-built version of the module and the version numbering for Qt Charts will then be changed so that it follows the Qt versioning.

Performance improvement

The biggest visible improvement done to Qt Charts 2.1.0 is a performance related change. For line and scatter series we’ve added support of accelerated drawing with OpenGL. The change radically improves performance in cases involving large data sets. We’ve added the OpenGL Accelerated Series Example to show how you can enable OpenGL acceleration for QLineSeries and QScatterSeries.

Large data set shown in the OpenGL Accelerated Series Example

New features and functionality in Qt Charts 2.1.0

• Reverse axis support
• Possibility to set labels position for QCategory Axis
• Support for minor ticks to value axis
• Support for bar series value label angle
• Points can be replaced and get as a QVector with QXYSeries
• Duration and easing curve can be set for chart animation
• Labels clipping can be enabled and disabled
• Possibility to remove more than one point from QXYSeries
• Color of the grid can be set with axis
• mapToPosition and mapToValue methods to ChartView
• Zooming functions to ChartView to correspond the ones available for QChart
• Changed signals to scatter series marker size and shape properties

In addition to the above changes there are also several fixes done based on customer reports. For detailed list of changes please see the dist/changes-2.1.0 file included in the source package of Qt Charts.

Qt Charts 2.1.0 is already included as a source package in Qt 5.6 Beta. The final Qt 5.6 release will also include the binaries for this add-on. In Qt 5.6 release the module binaries will still be available only with the commercial packages. Open source users can build the module from the sources. As always, Qt Charts is fully covered by our standard support. Should you have any issues using the module or in case you want to share your ideas for further development, please contact our support team through the Qt Account Support Center.

The post Qt Charts 2.1.0 Release appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1OZ0uAP

New agreement with the KDE Free Qt Foundation and changes for the open source version

Open Source and the Free Software movement have always played a very important role in Qt’s history. From the very beginning, Qt has been available under both Open Source and commercial licensing terms.

This dual licensing approach has played a major role in turning Qt into the technology it is today. While the commercial business funds the majority of the development work, the open source version has helped us grow the ecosystem of users and provided us with invaluable feedback and contributions improving the product.

KDE Free Qt Foundation

To show our commitment to this dual licensing model, the KDE Free Qt Foundation was founded in 1998. It is a non-profit foundation ensuring that Qt will always be available under open source licensing terms. The agreement that governs this foundation has stayed mainly unchanged over the last 17 years. As a lot of things have changed during these years, we have been working with KDE over the last year to create a new and updated agreement that takes todays realities better into account.

Nowadays, we have many more operating systems that are relevant to end users than we had when the original agreement was signed. To account for this, the updated agreement does not only cover X11 as in the original contract (Android got added around 3 years ago), but all major desktop and mobile operating systems. This includes Mac OS X, Windows, X11, Android, iOS and Windows Phone.

We are also now taking into account the fact that Qt is being developed in the open, with many other people in addition to the ones working for The Qt Company contributing to it. To respect the work of these people, the new contract ensures that all contributions, even if they aren’t yet part of a released version of Qt, are covered by the agreement.

Finally, the new agreement contains updates to the license requirements The Qt Company has when releasing a new version of Qt. Let’s have a look at those.

New license requirements

The new contract changes the licensing requirements for the open source version of Qt. The purpose here has been to bring the licensing of Qt more in line with the philosophy of the Free Software movement.

Free Software is about the freedom of the user to change and modify the code and to redistribute and use these changed and modified versions of the code. LGPL version 2.1 (LGPLv2.1) that we have been using as our main license does not ensure this freedom in the most effective way. For that reason, the Free Software Foundation created version 3 of the GPL (GPLv3) and LGPL (LGPLv3) a couple of years back.

LGPL version 3 differs from version 2.1 in two fundamental aspects. It explicitly protects the right of the end user to not only compile their modifications, but also deploy and run them on the target device. This essentially prevents the creation of fully locked-down devices. Secondly, it explicitly includes a protection against patent claims from the entity distributing code licensed under LGPLv3. These two additions greatly help protect the end users’ freedom when using source code licensed under LGPLv3.

For this reason, we added LGPLv3 as a licensing option to Qt with Qt 5.4 back in 2014, and have published new Qt modules under this license.

In line with this, the new contract with KDE now removes LGPLv2.1 as a required license for the open source version. Instead, it now requires LGPLv3 (and GPLv2 to keep license compatibility with some GPLv2 open source projects) for all existing frameworks and GPLv3 for our tooling and new add-ons.

Changes to our product offering

Licensing

Starting with Qt 5.7, we are planning to adjust Qt’s open source licensing to be in line with these ideas. At the same time, this allows us to open up the parts of Qt for application development that have previously only been available under commercial terms to the Free Software community, unifying the product.

So Qt 5.7 will not be available under LGPLv2.1 anymore. Instead, we will provide the different parts of Qt under the following licenses:

• Qt Essentials: All Qt Essentials will from now on be licensed under LGPLv3, GPLv2 and commercial license terms.
• Qt Add-ons: All Add-ons that are currently available in the open source version of Qt, will in the future be licensed under LGPLv3, GPLv2 and commercial license terms (Qt WebEngine in addition has a LGPLv2.1 requirement due to the 3rd party code from Chromium).Add-ons that were only available under commercial license terms in the past (e.g. Qt Charts and Qt Data Visualization) are now available under both GPLv3 and commercial license terms.
• Qt Tools and Applications: All tools (Qt Creator, moc, etc.) will in the future be available under commercial license terms and GPLv3. The GPL license comes with two exceptions that ensure that there are no license restrictions on generated code, and that bridging to 3rd party code is still possible.

This means that all parts of Qt for Application Development can be used under the GPLv3. Most parts can additionally be used under the LGPLv3 and GPLv2. Compatibility with GPLv2 will be kept where it is currently in place. All LGPL-licensed libraries inside Qt stay available under LGPLv3.

We believe that this combination of licenses for Qt is the best possible option to grow the Qt ecosystem further in the future.

In the embedded space, LGPLv3 in essence prevents the creation of locked-down devices. So any Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product. For desktop and mobile applications, the changes compared to LGPLv2.1 are smaller, but there are important clarifications for example related to mandatory patent license in case of distributing under LGPLv3 or GPLv3.

Unified product offering

With the contribution of these previously commercial-only modules and tools, we are removing the feature delta between the open source and commercial versions of Qt for Application Development. Publishing these add-ons under GPLv3 makes these available to the Free Software ecosystem, while at the same time keeping the incentives for commercial users to buy a license and help us fund further development of Qt.

The modules newly available to open source users are:

• Qt Charts
• Qt Data Visualization
• Qt Virtual Keyboard
• QML Profiler
• Clang static analyzer
• Qt Test Integration
• Qt Quick 2D renderer

Furthermore we will start work to integrate the Qt Quick Compiler functionality into the Qt QML module, targeting the Qt 5.8 release. At that point it will be available under LGPLv3/GPLv2/commercial license (the currently available Qt Quick Compiler will remain commercial-only for Qt version prior to Qt 5.8).

The source code for many of the modules has already been pushed to codereview.qt-project.org and we will push the remaining items in the coming days.

No changes to Qt 5.6 and Qt for Device Creation

Qt 5.6 and earlier versions will not be changed and continues to be available under the old licensing terms. Qt 5.6 is a long-term supported release, supported for three years after its release. We believe that this will give all users of the open source version enough time to adjust to the new licensing terms.

There are also no changes to Qt for Device Creation, which remains a commercial-only product.

Changes for commercial license holders?

It’s important to note that there are no changes to the commercially licensed version of Qt. But, we are convinced that these changes to the open source version will result in indirect benefits also for our commercial customers.

We believe these changes to lead to a better and more feature-rich Qt. This is due to the fact that the previously commercial only parts of Qt for Application Development will receive much broader testing and hopefully also contributions from the ecosystem. In addition, this change will help us extend the investments of The Qt Company into Qt and allow The Qt Company to focus more of its investments into the core part of the product.

Qt for Start-Ups

Over the last years, we have heard comments from many small companies and start-ups telling us that they would love to use the commercial version of Qt, but can’t afford the price of a full license. For these companies, we will in the coming months introduce a commercial start-up license for Qt for Application Development. This reduced-price offering will be limited to small companies and start-ups with annual revenue less than $100K.

Summing it all up

This change is the last step in a process we started about 1.5 years ago when we announced the one unified web site (www.qt.io) for Qt and that certain parts of Qt will only be available under LGPLv3 in the future. With this change, we can now fully unify our product offering. In the future, we will have one product called Qt for Application Development that comes with both commercial and open source licensing options.

The new licensing of the open source version of Qt is now much better aligned with our vision for Qt and the ecosystem around it. It is focused around the idea of a growing ecosystem where the open source version helps us extend the outreach and set of addressable devices for Qt application developers, and the commercial version generates the revenue to push the development of Qt as a product forward.

Feel free to also have a look at the corresponding announcement from KDE.

The post New agreement with the KDE Free Qt Foundation and changes for the open source version appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1Pr0y8H

Qt 3D: The Asset Conditioning Pipeline

Qt 3D development has been coming along nicely and is scheduled to be released with Qt 5.7.  One of the issues we face with offering a high-level 3D rendering API is facilitating the asset conditioning pipeline.  When dealing with 3D assets, there is a need to process the assets created in digital content creation applications like Maya, 3ds Max, or Blender into a format that makes sense for the rendering engine.  This is analogous to 2D asset conditioning pipeline where a designer creates an image in Adobe Illustrator (an .ai file), and before you use it in your application you convert it to PNG format.

What is an Asset Conditioning Pipeline?

Before diving into the implementation details of Qt 3D its worth explaining what an asset conditioning pipeline is.  Assets created in digital content creation applications are typically stored in data formats that reflect the needs and capabilities of that tool, and not the application you intend to use them.  The saved file will likely contain an abundance of extra data that is not relevant to your application leading to a larger storage need, as well as more time to load and put into use at runtime.  As an example, if we look at the data stored in a Blender file (.blend) in addition to containing geometry data, there is information specific to the Blender editor and renderer.  Information like the layouts of the editor, undo stack, modifiers, levels of detail etc.  There is also other really expensive things like high polygon models that are sculpted and used for baking additional assets like normal maps.  So even for a very simple model the file saved by the editor could have much unnecessary data that just takes up space in your deployment bundle, and in some cases the data it has is not in the most efficient format for how we will use it.

Many 3D content creation tools have the capability to export into file interchange formats like COLLADA.  These exporters are useful in the sense that they can strip out much of the excess data that is tool specific.  But while formats like COLLADA makes it easier to transfer 3D assets between content creation tools, they still don’t store data in a format facilitating efficient loading and usage. In addition, getting assets in the desired format is just not always possible. For instance, receiving a 40 MB car model in OBJ format from the design department is less than ideal, to put it mildly, but sometimes unavoidable in practice. It would be nice if developers could progress with the project regardless, without having to deal with asset loading times of several minutes.

Given those issues, the asset conditioning pipeline is responsible for transforming that asset file into a format that is useful for that intended task.  So stripping the asset of unnecessary data, and converting what is left to a format that can be easily and efficiently used by the rendering engine.

How does Qt 3D facilitate the asset conditioning pipeline?

Qt 3D is quite flexible in what assets can be used at runtime.  It is now possible to use any of the above formats directly in your application at runtime, despite the inefficiency. This is enabled by use of the Open Asset Import Library (libassimp).  We bundle this as a 3^rd party library with the Qt 3D module and provide a scene parser plugin that uses it to load a Qt 3D scene from an asset file.  This approach can be seen as using non-conditioned assets, or runtime conditioned assets, and will not be ideal for resource sensitive applications, especially on mobile and embedded platforms.

In addition to the Assimp scene parser plugin, we also have a plugin for loading GL Transmission Format (glTF) assets.  The glTF format like the COLLADA format is a Khronos-defined (draft) standard, but unlike COLLADA, glTF is designed for the efficient transmission and loading of 3D scenes and models for applications.  Assets bundled as glTF have geometry data, textures, and shaders all bundled in such a way that it is easy for Qt 3D to upload those assets to the GPU, and make use of them in the Qt 3D scene.  Because of this we choose glTF as the format to use for our asset conditioning tool.

Introducing qgltf

To get a quick overview, you may want to watch the recording of the lightning talk from Qt World Summit 2015 in Berlin:

The Qt tool qgltf is an application that is bundled with the Qt 3D module.  It is a host tool in the same way as qmake or moc, in that is built and run on the host machine.  The purpose of qgltf is to take an arbitrary 3D asset created with a digital content creation tool, and convert to glTF which will be loaded into a Qt 3D scene by the above mentioned glTF scene parser plugin.  By using the bundled Open Asset Importer Library in the qgltf tool, we are able to convert the same files Assimp scene parser can load into glTF for efficient loading. This also means that the number of dependencies for the Qt libraries on the target system can be reduced. This can be important for embedded systems in particular: there is no need to ship potentially large 3rd party libraries together with Qt when the assets are baked into a common, efficient format during build time.   

There are existing converter tools (for example COLLADA2GLTF) available that can convert 3D assets to glTF, and in some cases the output of these will be usable as-is by the Qt 3D’s glTF scene parser plugin.  However, besides the obvious issue of COLLADA not being the only commonly used format, glTF’s focus is on WebGL at the moment.  In Qt 3D we have support for all current OpenGL and OpenGL ES versions, which means that shaders for a given GLSL version built into the assets can be problematic. More importantly, it will often be desirable to use Qt 3D’s built-in materials instead of providing custom shaders (generated by the converter tool) for every asset. This way models and scenes can participate in Qt 3D’s standard lighting system. Therefore, in addition to a set of basic built-in shaders, qgltf promotes the use of extensions like KHR_materials_common which allow models to use Qt 3D’s own standard materials instead of asset-provided shaders and technique descriptions.

By using the qgltf tool we also have the possibility to bring further optimizations to the generated files.  Assets in glTF typically consist of several different standalone files.  The main asset file is the .gltf file which is a JSON file can that actually describes the scene itself.  With qgltf we can output this as a binary JSON file, or even a compressed version of that to get even more efficient loading times.  Generating tangent vectors and scaling vertices during build time are also supported. In case Qt 3D’s built-in materials are not deemed suitable, qgltf can generate techniques and shaders both for GLSL 1.00 and version 150 (suitable for OpenGL 3.2+ core profile contexts). Another experimental feature qgltf can provide is automatic compression of texture assets.  So if you have several texture files that are in PNG format, and you are deploying to a device that supports ETC1 compressed images, qgltf will make sure the asset it generates also contains and uses those compressed textures.

It is also important to point out that not every possible feature of glTF is in use: things that are better defined through Qt’s, QML’s and Qt 3D’s own powerful facilities are left out from the baked assets. This includes lights and animations (skeletal animations are on the roadmap for future releases, though). So in short, the tool’s focus is on converting and baking the parts of the assets that matter, nothing more, nothing less, into a format that is most efficient to deploy and load at runtime, even on I/O-bound embedded systems.

Usage of qgltf

Keeping with our tradition of flexibility, you also have a few options on how you can use the qgltf tool to best fit your workflow.  First can use it as a standalone command line tool that you can include in your existing asset import pipeline.  If you have the Qt 3D module installed alongside your Qt installation the qgltf tool exists at the same path as the other Qt tools (qmake, moc, uic).  If you are using qmake as your build system you also have the possibility to have qgltf run automatically when your application builds.  To do this you simply need to list your 3D model assets as followed in one of your qmake project files:

# 3D assets
QT3D_MODLES += assets/3d/car.obj
# Parameters for qgltf (use binary JSON and rely on Qt 3D's built-in materials)
QGLTF_PARAMS = -b -S
# load the qgltf qmake feature
load(qgltf)

This will convert the OBJ file into a glTF format file, and add it to a Qt resource file (.qrc) together with all the geometry and image files.  To make use of that model in your Qt 3D application you just need to load the generated file by setting it as the source in your SceneLoader. Everything else is managed automatically by the build system.

SceneLoader {
    source: “qrc:/models/car.qgltf”
}

What does the future hold?

Qt 3D is still quite new and under heavy development so there are still many possibilities that can be explored with regards to asset conditioning and other tooling.  We could for example have additional measures in qgltf that optimize the original mesh when possible.  We have also been looking into the possibility of generating a QML file along with the glTF asset that can facilitate the loading and easy access of elements (sub-meshes, materials, etc.) within the models and the scene.  And of course if you have any feedback or ideas we would love to hear them.

The post Qt 3D: The Asset Conditioning Pipeline appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1UBQrBO