The Qt 3D Studio application authoring environment is very powerful and open ended, allowing for basically endless design possibilities. Decisions that you make about how you author your content can have dramatic effects on the runtime performance of your UI. This document presents a few rules of thumb to keep in mind that will help you create presentations that perform well.

Scene Graph

The scene graph is the hierarchy of nodes that describe the scene to be rendered.

Inside Studio, the scene graph is represented by the tree-like view in the timeline. The scene graph is managed in realtime by the Qt 3D Studio Runtime, so by minimizing the size of the scene graph in Studio, you can minimize the work done by the Runtime.

In Qt 3D Studio this is the principal performance rule of thumb. Likely the single biggest impact you can have in terms of optimization when creating presentations with Studio is to keep the scene graph small. Although the data exported for runtime is aggressively optimized, it is still a good idea to avoid using unnecessary groups or layers as organizational tools, and to generally avoid complex hierarchy when possible.

If a presentation is becoming too large, consider whether it could be split into smaller logical units as separate presentations.

Components

Components in Studio can be thought of as scenes within the Scene.

Components, like a full presentation scene, have a timeline and their own set of slides (including a Master Slide). Each component's timeline runs independently of the rest of the scene, allowing for time-independent animations. Additionally, a component's separate set of slides (states) allow common functionality - for example that of a button, to be factored out and reused across presentations.

While these are very powerful concepts, it is important to understand the costs associated with using components.

• Adding slides to your components (or the Scene for that matter) will increase the file size and runtime memory requirements of your presentation. There is logic information stored to represent the state of each slide of each component, and while there are several optimizations in place to minimize the amount of data that needs to be stored, adding slides is still not "free".
• For each frame there is a small fixed cost associated with translating "global" time, which is generated by the Runtime outside of the presentation, into local time for each component. This translation has to occur, as a component might have a shorter (or longer) overall time bar than the Scene, and may otherwise be looping, ping-ponging or even stopped.
• Including components in your presentation also increases the complexity of your scene graph, and complex scene graphs deteriorate performance. Therefore, components should only be used when necessary, such as when you're leveraging their reusability or their time context (slides and independent timeline.)

Asset Complexity

It is entirely possible for the performance of your UI not to be bound by some calculation the Qt 3D Studio Runtime is doing, but instead to be bottlenecked at render time. Needless optimization is a waste of time, so there is no substitute for profiling to find out what the bottleneck is.

With that said, one possible point of optimization can be to simplify your assets.

• 3D models
  • Using the minimum number of triangles or vertices to achieve the desired look is always a good idea.
  • Hierarchy inside the content creation application is translated into hierarchy inside Studio. This can lead to complex scene graphs and therefore lower performance. It may be worthwhile to see if your 3D assets can be merged into larger meshes, assuming that the hierarchy is not necessary for placement or animation.
• Images
  • Plainly, smaller images require less memory and render faster.

File Size

Not surprisingly, the sizes of the various files related to Qt 3D Studio increase as presentation complexity increases. Titanic .uip files can be painful to edit in Studio, are slower to export and load and typically use more memory at runtime.

In general it is a good idea to try and keep file sizes down.

We recommend splitting different logical units of your UI (screens, sections) into separate presentations (.uip files). Doing this can result in smaller files as well as the possibility of distributing the work of creating the presentations among multiple artists. File save times in Studio are also directly related to presentation complexity, so splitting your UI into multiple .uip files can result in a better workflow and faster iterations (change/test cycles) of your UI.