diff options
Diffstat (limited to 'src/quick/doc/src/concepts/effects')
| -rw-r--r-- | src/quick/doc/src/concepts/effects/particles.qdoc | 34 | ||||
| -rw-r--r-- | src/quick/doc/src/concepts/effects/sprites.qdoc | 22 |
2 files changed, 28 insertions, 28 deletions
diff --git a/src/quick/doc/src/concepts/effects/particles.qdoc b/src/quick/doc/src/concepts/effects/particles.qdoc index 08a76511b6..708e8d2740 100644 --- a/src/quick/doc/src/concepts/effects/particles.qdoc +++ b/src/quick/doc/src/concepts/effects/particles.qdoc @@ -47,26 +47,26 @@ \inqmlmodule QtQuick.Particles 2.0 \title Using the Qt Quick Particle System - Documentation for all Particle System elements can be found on the \l{QtQuick.Particles 2}{QtQuick.Particles} module page. + Documentation for all Particle System types can be found on the \l{QtQuick.Particles 2}{QtQuick.Particles} module page. - Note that to use elements from the particles module, you will need to import the types with the following line: + Note that to use types from the particles module, you will need to import the types with the following line: \code import QtQuick.Particles 2.0 \endcode \section1 The ParticleSystem - This particle system contains four main types of QML Elements: ParticleSystem, Painters, Emitters and Affectors. + This particle system contains four main types of QML types: ParticleSystem, Painters, Emitters and Affectors. - The ParticleSystem element ties all the other elements together, and manages the shared timeline. Painters, Emitters + The ParticleSystem type ties all the other types together, and manages the shared timeline. Painters, Emitters and Affectors must all have the same ParticleSystem to be able to interact with each other. You may have as many ParticleSystems as you want subject to this constraint, so the logical separation is to have - one ParticleSystem for all the elements that you want to interact, or just one if the number of elements is small + one ParticleSystem for all the types that you want to interact, or just one if the number of types is small and they are easily kept under control.. \section1 Logical Particles - All the particle system elements act on "logical particles". Every particle has a logical representation inside - the particle system, and this is what the elements act upon. Not every logical particle needs to be visualized, + All the particle system types act on "logical particles". Every particle has a logical representation inside + the particle system, and this is what the types act upon. Not every logical particle needs to be visualized, and some logical particles could lead to multiple visual particles being drawn on screen. \section1 Particle Groups @@ -76,16 +76,16 @@ can have stochastic state transitions. Groups control particles because you can never access an individual particle with any of the particle system - elements. All elements act on groups as a whole, and so any particles that need to behave differently from each + types. All types act on groups as a whole, and so any particles that need to behave differently from each other (aside from the usual stochastic parameter variation) will need to be in different groups. Particles can also change groups dynamically. When this happens the particles trajectory is unaltered, but it can be acted upon by different ParticlePainters or Affectors. Particles can either have their group changed by - an Affector, or stochastic state transitions can be defined in a ParticleGroup element. + an Affector, or stochastic state transitions can be defined in a ParticleGroup type. Generally, groups should only be defined in a ParticleGroup if they require stochastic state transitions. Otherwise, it is sufficient to have the groups be defined simply by the strings used in the particle/particles properties - of the elements. + of the types. \section1 Emitters Emitters emit logical particles into the system. These particles have a trajectory and lifespan, but no visualization. @@ -96,16 +96,16 @@ were an Emitter on it with the same properties as the TrailEmitter. \section1 ParticlePainters - Painters are the elements that visualize logical particles. For each logical particle in the groups assigned to it, - which are within its bounds (or outside, if you do not set the clip property on the element) it will be visualized + Painters are the types that visualize logical particles. For each logical particle in the groups assigned to it, + which are within its bounds (or outside, if you do not set the clip property on the type) it will be visualized in a manner dependent on the type of ParticlePainter. The base type of ParticlePainter does not draw anything. ImageParticle renders an image at the particle location. CustomParticle allows you to write your own shaders to render the particles, passing in the logical particle state as vertex data. ItemParticle allows you to visualize logical particles using arbitrary QML delegates. ModelParticle is similar, but coordinates model data amongst the delegates in a similar manner to the view classes. - As the ParticlePainter is the QML element visualizing the particles in the scene, it is its Z value which is important - when trying to place particles above or below other elements visually. + As the ParticlePainter is the QML type visualizing the particles in the scene, it is its Z value which is important + when trying to place particles above or below other types visually. \section1 Affectors Affectors are an optional component of a particle system. They can perform a variety of manipulations to the simulation, @@ -115,7 +115,7 @@ \section1 Stochastic Parameters As particle systems benefit from stochastic control of parameters across a large number of instances, several stochastic helper types are used by the particle system. If you do not wish to have any stochastic variation in these parameters, - then do not specify any variation in these elements. + then do not specify any variation in these types. \section2 Directions Directions can be specified by angle and magnitude, or by x and y components. While any direction can be specified with @@ -124,9 +124,9 @@ to an arc centered on the specified point. \section2 Shapes - The particle system contains several elements which represent shapes. These elements do not visualize shapes, and are used + The particle system contains several types which represent shapes. These types do not visualize shapes, and are used for the purpose of selecting a random point within the shape. If you want a specific point with no randomness, use a 0 width - and 0 height shape (which is the default). Otherwise you can use the shape elements provides to specify an area, so that the + and 0 height shape (which is the default). Otherwise you can use the shape types to specify an area, so that the result can use a random point selected from that area. */ diff --git a/src/quick/doc/src/concepts/effects/sprites.qdoc b/src/quick/doc/src/concepts/effects/sprites.qdoc index ac3234b24c..7ee98a533b 100644 --- a/src/quick/doc/src/concepts/effects/sprites.qdoc +++ b/src/quick/doc/src/concepts/effects/sprites.qdoc @@ -79,7 +79,7 @@ immediately. \section2 Input Format -The file formats accepted by the sprite engine is the same as the file formats accepted by other QML elements, +The file formats accepted by the sprite engine is the same as the file formats accepted by other QML types, such as \l Image. In order to animate the image however, the sprite engine requires the image file to contain all of the frames of the animation. They should be arranged in a contiguous line, which may wrap from the right edge of the file to a lower row starting from the left edge of the file (and which is placed directly below the @@ -156,24 +156,24 @@ http://www.imagemagick.org/script/montage.php \section2 QML Types Using the Sprite Engine -Sprites for the sprite engine can be defined using the \l Sprite element. This element includes the input parameters +Sprites for the sprite engine can be defined using the \l Sprite type. This type includes the input parameters as well as the length of the animation and weighted transitions to other animations. It is purely a data class, and does not render anything. -\l SpriteSequence is an element which uses a sprite engine to draw the sprites defined in it. It is a single and -self-contained sprite engine, and does not interact with other sprite engines. \l Sprite elements can be shared between -sprite engine using elements, but this is not done automatically. So if you have defined a sprite in one \l SpriteSequence -you will need to redefine it (or reference the same \l Sprite element) in the sprites property of another \l SpriteSequence +\l SpriteSequence is a type which uses a sprite engine to draw the sprites defined in it. It is a single and +self-contained sprite engine, and does not interact with other sprite engines. \l Sprite types can be shared between +sprite engine using types, but this is not done automatically. So if you have defined a sprite in one \l SpriteSequence +you will need to redefine it (or reference the same \l Sprite type) in the sprites property of another \l SpriteSequence in order to transition to that animation. -Additionally, \l ImageParticle can use \l Sprite elements to define sprites for each particle. This is again a single -sprite engine per element. This works similarly to SpriteSequence, but it also has the parametrized variability provided -by the \l ImageParticle element. +Additionally, \l ImageParticle can use \l Sprite types to define sprites for each particle. This is again a single +sprite engine per type. This works similarly to SpriteSequence, but it also has the parametrized variability provided +by the \l ImageParticle type. \section1 AnimatedSprite -For use-cases which do not need to transition between animations, consider the \l AnimatedSprite element. -This element displays sprite animations with the same input format, but only one at a time. It also provides more fine-grained +For use-cases which do not need to transition between animations, consider the \l AnimatedSprite type. +This type displays sprite animations with the same input format, but only one at a time. It also provides more fine-grained manual control, as there is no sprite engine managing the timing and transitions behind the scenes. */ |