1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
/****************************************************************************
**
** Copyright (C) 1993-2009 NVIDIA Corporation.
** Copyright (C) 2017 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of Qt 3D Studio.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\title Creating Optimized Presentations
\page best-practices-creating-optimized-presentations.html
\ingroup qt3dstudio-best-practices
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.
\section1 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.
\section1 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.
\list
\li
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\".
\li
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.
\li
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.)
\endlist
\omit
TODO: Rewrite or remove
\section1 Behaviors
Behaviors are script code that affect the presentation at runtime.
Here are a few key optimization and performance rules of thumb to keep
in mind while writing scripts.
\list
\li
Less script code is better.
\li
The fastest code is no code at all. Excessively long scripts are
typically also more difficult to debug, so there is no shortage of
motivation to keep scripts short and sweet.
\li
Caching values can improve performance.
\li
Use \c{onUpdate} judiciously.
\li
A behavior's \c{onUpdate} handler, which can be used to execute
code every frame, is a very powerful concept that enables a lot of the
neat things behaviors can do in the Runtime.
\li
By its very nature, each behavior instance with an \c{onUpdate}
handler will cause (at least) one function call every frame, and this
can add up. Therefore, it is important to keep the number of
\c{onUpdate} handlers to a minimum, and to ensure that each
\c{onUpdate} handler is doing as little as possible. Consider an
early-outing if that can minimize the code run each frame.
\li
If an \c{onUpdate} handler is being used to poll something,
consider whether it would be possible to use an event-driven approach
instead, or if there are several instances of the behavior with
\c{onUpdate} consider having some kind of \"manager\" behavior
that would have a single \c{onUpdate} that would encompass the
functionality of each of the behavior instance's \c{onUpdate}.
\endlist
\endomit
\section1 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.
\list
\li
\b{3D models}
\list
\li
Using the minimum number of triangles or vertices to achieve the
desired look is always a good idea.
\li
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.
\endlist
\li
\b{Images}
\list
\li
Plainly, smaller images require less memory and render faster.
\endlist
\endlist
\section1 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 \c{.uip} files can result in a
better workflow and faster iterations (change/test cycles) of your UI.
*/
|
