AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
0d5d142f6e
skia2/tools/viewer/ParticlesSlide.cpp

296 lines
9.1 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.
*/
#include "ParticlesSlide.h"
Add curve visualization back, guard eval Editing curves is still cumbersome, but that's fine. Visualization is just for feedback (and imgui's path renderer is a little wonky), but this helps a bit. Bug: skia: Change-Id: I3dace6d822d472314513bb1ad72bcea1e8991b77 Reviewed-on: https://skia-review.googlesource.com/c/192828 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 15:45:56 +00:00
#include "ImGuiLayer.h"
change particleslide to use Resources standard way to find assets across different platforms Bug: skia: Change-Id: I4cb464be1e643a59431eba66b5caad70ecfed1e9 Reviewed-on: https://skia-review.googlesource.com/c/196775 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Mike Reed <reed@google.com>
2019-03-02 22:57:20 +00:00
#include "Resources.h"
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
#include "SkParticleAffector.h"
Moved image params out to SkParticleDrawable Added a simpler circle drawable, moved drawing code out so that frame calculation is handled by the drawable. Fixed all the sample effects, including some size adjustments to better create the intended effect. Bug: skia: Change-Id: I60af9cd6262ff98352ca8ceaf6768aef9c7e164c Reviewed-on: https://skia-review.googlesource.com/c/193029 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 19:29:38 +00:00
#include "SkParticleDrawable.h"
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
#include "SkParticleEffect.h"
#include "SkParticleSerialization.h"
#include "SkReflected.h"
#include "imgui.h"
using namespace sk_app;
namespace {
static SkScalar kDragSize = 8.0f;
static SkTArray<SkPoint*> gDragPoints;
int gDragIndex = -1;
}
///////////////////////////////////////////////////////////////////////////////
static int InputTextCallback(ImGuiInputTextCallbackData* data) {
if (data->EventFlag == ImGuiInputTextFlags_CallbackResize) {
SkString* s = (SkString*)data->UserData;
SkASSERT(data->Buf == s->writable_str());
SkString tmp(data->Buf, data->BufTextLen);
s->swap(tmp);
data->Buf = s->writable_str();
}
return 0;
}
class SkGuiVisitor : public SkFieldVisitor {
public:
SkGuiVisitor() {
fTreeStack.push_back(true);
}
#define IF_OPEN(WIDGET) if (fTreeStack.back()) { WIDGET; }
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, float& f) override {
IF_OPEN(ImGui::DragFloat(item(name), &f))
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
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, int& i) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::DragInt(item(name), &i))
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
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, bool& b) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::Checkbox(item(name), &b))
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
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkString& s) 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
if (fTreeStack.back()) {
ImGuiInputTextFlags flags = ImGuiInputTextFlags_CallbackResize;
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::InputText(item(name), s.writable_str(), s.size() + 1, flags, InputTextCallback,
&s);
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
}
}
Particles: remove non-stable random, add better enum reflection The other generator was never used (or useful). String-based serialization of enums is quite helpful, though. Bug: skia: Change-Id: Ic9d58f8d20cfe7aba47722bd74f1e6f8f0f219e5 Reviewed-on: https://skia-review.googlesource.com/c/195368 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-26 19:58:40 +00:00
void visit(const char* name, int& i, const EnumStringMapping* map, int count) override {
if (fTreeStack.back()) {
const char* curStr = EnumToString(i, map, count);
if (ImGui::BeginCombo(item(name), curStr ? curStr : "Unknown")) {
for (int j = 0; j < count; ++j) {
if (ImGui::Selectable(map[j].fName, i == map[j].fValue)) {
i = map[j].fValue;
}
}
ImGui::EndCombo();
}
}
}
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
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkPoint& p) 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
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::DragFloat2(item(name), &p.fX);
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
gDragPoints.push_back(&p);
}
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkColor4f& c) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::ColorEdit4(item(name), c.vec()))
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
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
#undef IF_OPEN
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
void visit(sk_sp<SkReflected>& e, const SkReflected::Type* baseType) override {
if (fTreeStack.back()) {
const SkReflected::Type* curType = e ? e->getType() : nullptr;
if (ImGui::BeginCombo("Type", curType ? curType->fName : "Null")) {
auto visitType = [curType,&e](const SkReflected::Type* t) {
if (ImGui::Selectable(t->fName, curType == t)) {
e = t->fFactory();
}
};
SkReflected::VisitTypes(visitType, baseType);
ImGui::EndCombo();
}
}
}
void enterObject(const char* name) override {
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
fTreeStack.push_back(ImGui::TreeNodeEx(item(name),
ImGuiTreeNodeFlags_AllowItemOverlap));
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
} else {
fTreeStack.push_back(false);
}
}
void exitObject() override {
if (fTreeStack.back()) {
ImGui::TreePop();
}
fTreeStack.pop_back();
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
int enterArray(const char* name, int oldCount) override {
this->enterObject(item(name));
fArrayCounterStack.push_back(0);
fArrayEditStack.push_back();
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
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
int count = oldCount;
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
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::SameLine();
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
if (ImGui::Button("+")) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
++count;
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
}
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
return count;
}
ArrayEdit exitArray() override {
fArrayCounterStack.pop_back();
auto edit = fArrayEditStack.back();
fArrayEditStack.pop_back();
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
this->exitObject();
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
return edit;
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
}
private:
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
const char* item(const char* name) {
if (name) {
return name;
}
// We're in an array. Add extra controls and a dynamic label.
int index = fArrayCounterStack.back()++;
ArrayEdit& edit(fArrayEditStack.back());
fScratchLabel = SkStringPrintf("[%d]", index);
ImGui::PushID(index);
if (ImGui::Button("X")) {
edit.fVerb = ArrayEdit::Verb::kRemove;
edit.fIndex = index;
}
ImGui::SameLine();
if (ImGui::Button("^")) {
edit.fVerb = ArrayEdit::Verb::kMoveForward;
edit.fIndex = index;
}
ImGui::SameLine();
if (ImGui::Button("v")) {
edit.fVerb = ArrayEdit::Verb::kMoveForward;
edit.fIndex = index + 1;
}
ImGui::SameLine();
ImGui::PopID();
return fScratchLabel.c_str();
}
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
SkSTArray<16, bool, true> fTreeStack;
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
SkSTArray<16, int, true> fArrayCounterStack;
SkSTArray<16, ArrayEdit, true> fArrayEditStack;
SkString fScratchLabel;
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<SkParticleEffectParams> LoadEffectParams(const char* filename) {
sk_sp<SkParticleEffectParams> params(new SkParticleEffectParams());
change particleslide to use Resources standard way to find assets across different platforms Bug: skia: Change-Id: I4cb464be1e643a59431eba66b5caad70ecfed1e9 Reviewed-on: https://skia-review.googlesource.com/c/196775 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Mike Reed <reed@google.com>
2019-03-02 22:57:20 +00:00
if (auto fileData = GetResourceAsData(filename)) {
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
skjson::DOM dom(static_cast<const char*>(fileData->data()), fileData->size());
SkFromJsonVisitor fromJson(dom.root());
params->visitFields(&fromJson);
}
return params;
}
ParticlesSlide::ParticlesSlide() {
// Register types for serialization
REGISTER_REFLECTED(SkReflected);
SkParticleAffector::RegisterAffectorTypes();
Moved image params out to SkParticleDrawable Added a simpler circle drawable, moved drawing code out so that frame calculation is handled by the drawable. Fixed all the sample effects, including some size adjustments to better create the intended effect. Bug: skia: Change-Id: I60af9cd6262ff98352ca8ceaf6768aef9c7e164c Reviewed-on: https://skia-review.googlesource.com/c/193029 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 19:29:38 +00:00
SkParticleDrawable::RegisterDrawableTypes();
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
fName = "Particles";
Defer loading particle effect to load time. Moving this out of the constructor means less going on at slide creation time, making debugging easier. Change-Id: I37bdd249abef663931bc8ef152a92a3a3436dcf4 Reviewed-on: https://skia-review.googlesource.com/c/192600 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Ben Wagner <bungeman@google.com>
2019-02-14 18:22:43 +00:00
}
void ParticlesSlide::load(SkScalar winWidth, SkScalar winHeight) {
change particleslide to use Resources standard way to find assets across different platforms Bug: skia: Change-Id: I4cb464be1e643a59431eba66b5caad70ecfed1e9 Reviewed-on: https://skia-review.googlesource.com/c/196775 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Mike Reed <reed@google.com>
2019-03-02 22:57:20 +00:00
fEffect.reset(new SkParticleEffect(LoadEffectParams("particles/default.json"),
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
fRandom));
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
}
void ParticlesSlide::draw(SkCanvas* canvas) {
canvas->clear(0);
gDragPoints.reset();
Fix layout feedback loop in particle GUI Bug: skia: Change-Id: I6c5a846ed7b896d3eea27893bd946d7d0dd3f7d6 Reviewed-on: https://skia-review.googlesource.com/c/193375 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 21:25:50 +00:00
if (ImGui::Begin("Particles", nullptr, ImGuiWindowFlags_AlwaysVerticalScrollbar)) {
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
static bool looped = true;
ImGui::Checkbox("Looped", &looped);
if (fTimer && ImGui::Button("Play")) {
fEffect->start(*fTimer, looped);
}
Add SkParticleValue to allow further customization of curve behavior All curves (and path affectors) are driven by an SkParticleValue. The value can derive its value from the current defaults (age of particle or effect), or explicitly choose the other one, a random value, or any other particle value. Values can be range adjusted and support repeat, clamp, and mirror tiling. Also fixed some more issues related to resource path in the slide GUI. Bug: skia: Change-Id: I4755018d5b57ae2d5ec400d541055ca4fb542978 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/196760 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-04 15:55:22 +00:00
static char filename[64] = "particles/default.json";
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
ImGui::InputText("Filename", filename, sizeof(filename));
if (ImGui::Button("Load")) {
if (auto newParams = LoadEffectParams(filename)) {
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
fEffect.reset(new SkParticleEffect(std::move(newParams), fRandom));
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
}
}
ImGui::SameLine();
if (ImGui::Button("Save")) {
Add SkParticleValue to allow further customization of curve behavior All curves (and path affectors) are driven by an SkParticleValue. The value can derive its value from the current defaults (age of particle or effect), or explicitly choose the other one, a random value, or any other particle value. Values can be range adjusted and support repeat, clamp, and mirror tiling. Also fixed some more issues related to resource path in the slide GUI. Bug: skia: Change-Id: I4755018d5b57ae2d5ec400d541055ca4fb542978 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/196760 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-04 15:55:22 +00:00
SkString fullPath = GetResourcePath(filename);
SkFILEWStream fileStream(fullPath.c_str());
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
if (fileStream.isValid()) {
SkJSONWriter writer(&fileStream, SkJSONWriter::Mode::kPretty);
SkToJsonVisitor toJson(writer);
writer.beginObject();
fEffect->getParams()->visitFields(&toJson);
writer.endObject();
writer.flush();
fileStream.flush();
} else {
SkDebugf("Failed to open file\n");
}
}
SkGuiVisitor gui;
fEffect->getParams()->visitFields(&gui);
}
ImGui::End();
SkPaint dragPaint;
dragPaint.setColor(SK_ColorLTGRAY);
dragPaint.setAntiAlias(true);
SkPaint dragHighlight;
dragHighlight.setStyle(SkPaint::kStroke_Style);
dragHighlight.setColor(SK_ColorGREEN);
dragHighlight.setStrokeWidth(2);
dragHighlight.setAntiAlias(true);
for (int i = 0; i < gDragPoints.count(); ++i) {
canvas->drawCircle(*gDragPoints[i], kDragSize, dragPaint);
if (gDragIndex == i) {
canvas->drawCircle(*gDragPoints[i], kDragSize, dragHighlight);
}
}
fEffect->draw(canvas);
}
bool ParticlesSlide::animate(const SkAnimTimer& timer) {
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
fTimer = &timer;
fEffect->update(timer);
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
return true;
}
bool ParticlesSlide::onMouse(SkScalar x, SkScalar y, Window::InputState state, uint32_t modifiers) {
if (gDragIndex == -1) {
if (state == Window::kDown_InputState) {
float bestDistance = kDragSize;
SkPoint mousePt = { x, y };
for (int i = 0; i < gDragPoints.count(); ++i) {
float distance = SkPoint::Distance(*gDragPoints[i], mousePt);
if (distance < bestDistance) {
gDragIndex = i;
bestDistance = distance;
}
}
return gDragIndex != -1;
}
} else {
// Currently dragging
SkASSERT(gDragIndex < gDragPoints.count());
gDragPoints[gDragIndex]->set(x, y);
if (state == Window::kUp_InputState) {
gDragIndex = -1;
}
return true;
}
return false;
}
Reference in New Issue Copy Permalink