Proposal: Animation System Redesign

[miogds]

While working on the edit split, many of the decoupling efforts I’ve been making—mainly through creating classes with a singleton pattern—are helping us gain customization while still allowing global access for functions that need it.

However, I’ve encountered a challenge:
The current animation system is essentially all-or-nothing. Right now, animations can only be enabled or disabled globally. While this might be fine for a packaged game build (where you either want animations on or off), it falls short in the editor workflow.

In the editor, animation needs to be more granular. For example:

• In the main scene view, you might want animations disabled to focus on static world editing.
• In a preview panel (e.g., for assets or prefabs), you need animations enabled to see how they behave in isolation.

This mismatch makes the current design inflexible for real-world usage.

---

Problem

The limitation is that the system doesn’t allow per-entity or per-view control. This means that:

• Turning off animations in one view turns them off everywhere.
• Testing assets or specific behaviors in isolation becomes cumbersome.
• Editor workflows are unnecessarily constrained.

---

Proposed Solution

Introduce a three-tier animation control system:

1. Per-Entity Control

   • Allow enabling/disabling animation at the entity level.
   • This setting could optionally propagate to child entities.

2. Per-View Control

   • Each editor view (scene, asset preview, secondary panels) should be able to independently toggle animations.
   • This enables workflows like static world editing + animated previews at the same time.

3. Global Control

   • Retain the current global on/off toggle for the entire app.
   • Useful for final builds, performance testing, or broad editor preferences.

---

Open Questions for Discussion

• Should per-entity animation toggles override global and per-view settings, or should they be subordinate?
• How should propagation to child entities be handled (default on, opt-in, opt-out)?
• Is there a clean way to avoid redundant state checks when layering per-entity, per-view, and global controls?
• Do we need editor-specific UI controls for per-view animation toggles, or should these live in a central settings panel?
• AnimationComponent could be a good way to implement on/off animation at entity level or view level?

---

Next Steps

• Align on the priority of control layers (which takes precedence).
• Decide on the propagation model for entity-level toggles.
• Outline a migration path from the current system to this redesigned approach.

---

👉 What do you think?

[untoldengine]

Thanks for writing this up — I think you’ve nailed the core limitation of the current system. The global toggle works fine for packaged builds, but as you point out, it really limits what we can do in the editor. Having finer-grained animation control will definitely improve the workflow.

I agree that we should move forward with a redesign along the lines of your proposal. A three-tiered model (Global → View → Entity) makes sense to me, since it matches how developers actually use the editor:

• Global stays as the master switch (good for builds and perf testing).
• Per-view toggles let us pause animation in the main scene while still previewing assets.
• Per-entity control gives flexibility when you only want to freeze or force playback for specific objects.

For precedence, my initial thought is:

• Start with Effective = Global && View.
• Let the entity policy (inherit / force on / force off) override that.

So, to clarify:

• If Global = Off → everything is off, regardless of View.
• If Global = On but View = Off → that view won’t animate.
• If both are On → animations are allowed in that view.

for entities:

• Inherit → follow the Effective value above.
• Force On → ignore Effective and animate no matter what.
• Force Off → ignore Effective and never animate.

This way the rule is simple and predictable. We can always refine it later if needed.

AnimationComponent is a good way to implement on/off animation at the entity level, so it stays consistent with the ECS design.

For editor UX, a per-view play/pause button in each panel and an inspector dropdown for entity policy feels natural.

What do you think?

[miogds]

Totally agree. I will draft a proposal this week, a first implementation so we can move forward with the changes.