One day at work, my neighbouring graphics programmer casually rolled over and asked “So we’re thinking of redoing the effects editor, do you have any thoughts on how it should work?”.
The short and simple answer would of course have been to just state
what’s missing and what could be improved, but instead I started
thinking about the nature of effects editors, and why they look and work
the way they do. I have a lot of thoughts, so be prepared for some
verbosity.
As far as game art goes, effects work is absolutely one of the more
technical disciplines. It strikes a razor-thin balance between classic
art theory concepts such as color and composition, a sense of timing and
impact often perfected by full-time animators, and lastly, a great deal
of technical know-how.
Modern effects editors, in my mind, tend to focus less on the
compositional, artistic, or animated process of effects authoring –
instead making it a process focused on tweaking numbers. Let me make my
case by quickly summarizing the major approaches we have to effects
authoring:
Spreadsheet Editors
Spreadsheet editors are what we’re given in most tools currently.
Unity, Unreal, Frostbite, and who knows how many other engines have all
opted to give us an interface where you’re presented with a number of
fields where you can type in numbers, and thus author your effects. Some
of these editors allow for advanced features such as supporting
expressions or animating values over time, some of them provide a
preview that updates in realtime while others require resaving and
rebuilding after each change, but in terms of interaction they are all
largely the same.
Node Editors
While still a relatively rare sight in realtime applications, node
editors are definitely on the rise. They have a storied and proud
heritage in offline applications such as 3ds Max, Softimage, and
Houdini. The mythical beast Niagara
has certain node-based components, but I’ll withhold judgement until
it’s been properly released. Frostbite also implements a graph-based
system for authoring GPU particle systems. As with shader graphs, they
are doing a strong effort of making the authoring of effects less
text-based and more interaction-based, but the concepts and vocabulary
is generally identical.
Script Editors
Script Editors refer to systems such as PopcornFX or what was used in Infamous: Second Son
where particle behavior is primarily driven through scripts and
expressions. This approach is powerful and flexible, and lends itself
well to people comfortable with programming. But for all the freedom and
power they offer, I would consider these editors the weakest in terms
of intuitivity and artist-friendliness.
The Problem
My issue with the above approaches all the assumptions from which
their foundation is built. While they differ in terms of iterability and
intuitiveness, they all originate from an assumption that effects work is a technical undertaking.
It’s not simply a matter of making tools more “artist friendly”
(whatever that means), it’s a matter of changing our vocabulary to
something less abstract and mathematical. Let’s imagine a world where
effects authoring is closer to 3D sculpting or character animation
rather than programming. Some ideas of what we’d potentially see:
-
The above approaches all have a focus on text entry, but rather
than typing coordinates and dimensions for emission volumes, why not
just place and scale them using the same manipulation tools we use for
other 3d models? Speed and direction could be represented as arrows or
vector fields, and adjusted directly (similar to what we see in Impromptu Vector Field Painter). Trajectories could be drawn directly in the viewport as splines without the hassle of modulating XYZ velocities over life.
-
Particle systems treat its content as points in space with sizes
and velocities, no matter what they’re trying to mimic. Fire is not
defined by its heat, and rock is not defined by its mass. This creates a
dissonance when we at the same time insist on defining a constant
downward force as gravity or define wind speeds in physical units such as m/s.
There is a discussion to be had in regards to how we can define and
achieve physically correct visual effects in games, but that would
easily warrant its own dedicated post.
The above examples illustrate what happens when we approach effects work as something tangible.
When we describe particle systems by what we’re trying to create rather
than describing them as point positions and spawn properties. Not only
would these systems be more approachable by artists with non-technical
backgrounds, we would achieve a workflow that is more iterable, more art
directable, and most importantly, more stimulating to work with.
It’s of course easy to be opinionated when I’m not in charge of the
implementation, but I maintain that it’s an important exercise to
second-guess the nature of the tools we use on a daily basis. I would
like for effects artists and engineers to spend some time reevaluating
our assumptions regarding effects authoring, because the notion that
effects authoring is a technical exercise rather than an artistic one
is informing the way our tools are being designed. The prevalence
of the spreadsheet approach is is typical and disheartening example,
since it demonstrates a lack of imagination in terms of how we see
artists authoring effects. I believe we can change the way we work with
effects systems without having to change a single line of backend code –
it is just our interaction with the systems that need rethinking.
I can’t wait to see new paradigms for effects authoring be invented, and discover what we’ll be able to create at that time.
