Commit Graph

2 Commits

Author SHA1 Message Date
Brian Osman
125daa4d1a 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 18:01:00 +00:00
Brian Osman
7c979f52c3 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:53:41 +00:00