AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
0c48681e58
skia2/modules/particles/include/SkParticleAffector.h

62 lines
2.2 KiB
C
Raw Normal View History

Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
/*
* Copyright 2019 Google LLC
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
#ifndef SkParticleAffector_DEFINED
#define SkParticleAffector_DEFINED
#include "SkReflected.h"
#include "SkPoint.h"
Refactor and further generalization of particle model - Collapsed the per-particle data into a single struct, and use that to communicate with drawables, too. Let the drawables manage allocation of xforms, colors, etc. Helpful for non-atlas drawables, and just to keep the effect code simpler. - Having all of the params in a single struct allows us to move the remaining animated behaviors into affectors (color/frame). - Added SkColorCurve, which works like SkCurve for SkColor4f. Use that to create a color affector (rather than simple start/end colors in the effect params). - Also put the stable random in SkParticleState. This is going to be necessary if/when we change affectors to operate on all particles (rather than one at a time). Still need to move t value into the particle struct (or eval it from the lifetime params on demand). Change-Id: Icf39116acbfd5d6e8eb91e9affbd8898d106211d Reviewed-on: https://skia-review.googlesource.com/c/193473 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-20 17:25:20 +00:00
struct SkColorCurve;
New SkCurve type with multiple curve segments - Converted all linear force stuff into a single affector, used at either spawn or update time appropriately. The new affector can either set or adjust velocity. - Converted lifetime to a curve. - Removed SkRangedFloat, initial velocity params, etc. Looks like a large addition, but that's mostly down to the JSON getting bigger. There's a net reduction in LoC. Bug: skia: Change-Id: Iac7417f15f96d0313efd08c4b26dc3250b80fa77 Reviewed-on: https://skia-review.googlesource.com/c/192102 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 21:55:21 +00:00
struct SkCurve;
Refactor and further generalization of particle model - Collapsed the per-particle data into a single struct, and use that to communicate with drawables, too. Let the drawables manage allocation of xforms, colors, etc. Helpful for non-atlas drawables, and just to keep the effect code simpler. - Having all of the params in a single struct allows us to move the remaining animated behaviors into affectors (color/frame). - Added SkColorCurve, which works like SkCurve for SkColor4f. Use that to create a color affector (rather than simple start/end colors in the effect params). - Also put the stable random in SkParticleState. This is going to be necessary if/when we change affectors to operate on all particles (rather than one at a time). Still need to move t value into the particle struct (or eval it from the lifetime params on demand). Change-Id: Icf39116acbfd5d6e8eb91e9affbd8898d106211d Reviewed-on: https://skia-review.googlesource.com/c/193473 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-20 17:25:20 +00:00
struct SkParticleState;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
struct SkParticleUpdateParams;
Few more particle features and some generalization work Add particle "frame" enum, to allow effects relative to local, world, or velocity. Remove the "orient along velocity" and replace with a much more general orientation affector (angle curve + frame). Add an angular velocity affector to mirror the behavior of the linear velocity affector. Bug: skia: Change-Id: Ibbaaeb352c9547d00d81c7916d00148dd65ed2b9 Reviewed-on: https://skia-review.googlesource.com/c/195361 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-26 15:02:15 +00:00
enum SkParticleFrame {
kWorld_ParticleFrame, // "Up" is { 0, -1 }
kLocal_ParticleFrame, // "Up" is particle's heading
kVelocity_ParticleFrame, // "Up" is particle's direction of travel
};
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
class SkParticleAffector : public SkReflected {
public:
REFLECTED_ABSTRACT(SkParticleAffector, SkReflected)
Change particle affector to work on N particles This should severely cut down on the virtual call overhead when running affectors. It also switches to model of "for each affector, do each particle", rather than "for each particle, do each affector". This is going to be an I$ improvement, and (if we ever care), make it possible to do wide-mode threading of the affectors on disjoint blocks of particles. Bug: skia: Change-Id: Ia4e8e8d461dba4e303c45766ea2b4ece1bca9196 Reviewed-on: https://skia-review.googlesource.com/c/195123 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-25 19:30:44 +00:00
void apply(SkParticleUpdateParams& params, SkParticleState ps[], int count);
Add "enabled" flag to affectors, fix curve interaction with stable random Flag is helpful while editing things (and could be a useful property to animate, as well). The curve change fixes a bug where the stable generator gets out of phase if all segments of a curve don't use the same options. Bug: skia: Change-Id: Ie151e775aee22957e79fa88feaafad72b6c781ff Reviewed-on: https://skia-review.googlesource.com/c/195120 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-25 19:15:02 +00:00
void visitFields(SkFieldVisitor* v) override;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
static void RegisterAffectorTypes();
Few more particle features and some generalization work Add particle "frame" enum, to allow effects relative to local, world, or velocity. Remove the "orient along velocity" and replace with a much more general orientation affector (angle curve + frame). Add an angular velocity affector to mirror the behavior of the linear velocity affector. Bug: skia: Change-Id: Ibbaaeb352c9547d00d81c7916d00148dd65ed2b9 Reviewed-on: https://skia-review.googlesource.com/c/195361 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-26 15:02:15 +00:00
// Affectors that can set the linear or angular velocity. Both have a 'force' option to apply
// the resulting value as a force, rather than directly setting the velocity.
New SkCurve type with multiple curve segments - Converted all linear force stuff into a single affector, used at either spawn or update time appropriately. The new affector can either set or adjust velocity. - Converted lifetime to a curve. - Removed SkRangedFloat, initial velocity params, etc. Looks like a large addition, but that's mostly down to the JSON getting bigger. There's a net reduction in LoC. Bug: skia: Change-Id: Iac7417f15f96d0313efd08c4b26dc3250b80fa77 Reviewed-on: https://skia-review.googlesource.com/c/192102 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 21:55:21 +00:00
static sk_sp<SkParticleAffector> MakeLinearVelocity(const SkCurve& angle,
const SkCurve& strength,
Add local vs world flag for particle velocity Adjust reference frame for affector to be consistent (so angles are counted clockwise from "up" in both local and world modes). Bug: skia: Change-Id: I643e1484bc0a58d1f1c0cfe35ac2ab37dc2ea409 Reviewed-on: https://skia-review.googlesource.com/c/194189 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-22 16:48:18 +00:00
bool force,
Few more particle features and some generalization work Add particle "frame" enum, to allow effects relative to local, world, or velocity. Remove the "orient along velocity" and replace with a much more general orientation affector (angle curve + frame). Add an angular velocity affector to mirror the behavior of the linear velocity affector. Bug: skia: Change-Id: Ibbaaeb352c9547d00d81c7916d00148dd65ed2b9 Reviewed-on: https://skia-review.googlesource.com/c/195361 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-26 15:02:15 +00:00
SkParticleFrame frame);
static sk_sp<SkParticleAffector> MakeAngularVelocity(const SkCurve& strength,
bool force);
// Set the orientation of a particle, relative to the world, local, or velocity frame.
static sk_sp<SkParticleAffector> MakeOrientation(const SkCurve& angle,
SkParticleFrame frame);
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
static sk_sp<SkParticleAffector> MakePointForce(SkPoint point, SkScalar constant,
SkScalar invSquare);
New SkCurve type with multiple curve segments - Converted all linear force stuff into a single affector, used at either spawn or update time appropriately. The new affector can either set or adjust velocity. - Converted lifetime to a curve. - Removed SkRangedFloat, initial velocity params, etc. Looks like a large addition, but that's mostly down to the JSON getting bigger. There's a net reduction in LoC. Bug: skia: Change-Id: Iac7417f15f96d0313efd08c4b26dc3250b80fa77 Reviewed-on: https://skia-review.googlesource.com/c/192102 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 21:55:21 +00:00
Refactor and further generalization of particle model - Collapsed the per-particle data into a single struct, and use that to communicate with drawables, too. Let the drawables manage allocation of xforms, colors, etc. Helpful for non-atlas drawables, and just to keep the effect code simpler. - Having all of the params in a single struct allows us to move the remaining animated behaviors into affectors (color/frame). - Added SkColorCurve, which works like SkCurve for SkColor4f. Use that to create a color affector (rather than simple start/end colors in the effect params). - Also put the stable random in SkParticleState. This is going to be necessary if/when we change affectors to operate on all particles (rather than one at a time). Still need to move t value into the particle struct (or eval it from the lifetime params on demand). Change-Id: Icf39116acbfd5d6e8eb91e9affbd8898d106211d Reviewed-on: https://skia-review.googlesource.com/c/193473 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-20 17:25:20 +00:00
static sk_sp<SkParticleAffector> MakeSize(const SkCurve& curve);
static sk_sp<SkParticleAffector> MakeFrame(const SkCurve& curve);
static sk_sp<SkParticleAffector> MakeColor(const SkColorCurve& curve);
Add "enabled" flag to affectors, fix curve interaction with stable random Flag is helpful while editing things (and could be a useful property to animate, as well). The curve change fixes a bug where the stable generator gets out of phase if all segments of a curve don't use the same options. Bug: skia: Change-Id: Ie151e775aee22957e79fa88feaafad72b6c781ff Reviewed-on: https://skia-review.googlesource.com/c/195120 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-25 19:15:02 +00:00
private:
Change particle affector to work on N particles This should severely cut down on the virtual call overhead when running affectors. It also switches to model of "for each affector, do each particle", rather than "for each particle, do each affector". This is going to be an I$ improvement, and (if we ever care), make it possible to do wide-mode threading of the affectors on disjoint blocks of particles. Bug: skia: Change-Id: Ia4e8e8d461dba4e303c45766ea2b4ece1bca9196 Reviewed-on: https://skia-review.googlesource.com/c/195123 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-25 19:30:44 +00:00
virtual void onApply(SkParticleUpdateParams& params, SkParticleState ps[], int count) = 0;
Add "enabled" flag to affectors, fix curve interaction with stable random Flag is helpful while editing things (and could be a useful property to animate, as well). The curve change fixes a bug where the stable generator gets out of phase if all segments of a curve don't use the same options. Bug: skia: Change-Id: Ie151e775aee22957e79fa88feaafad72b6c781ff Reviewed-on: https://skia-review.googlesource.com/c/195120 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-25 19:15:02 +00:00
bool fEnabled = true;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
};
#endif // SkParticleAffector_DEFINED
Reference in New Issue Copy Permalink