Animate anything in Unity the way you edit video - visually, in the UI, with almost no code.
A UI-first animation system for Unity 6 · Node graph · Timeline editors · Rig-agnostic · Zero-allocation runtime

Overview

Honami replaces Unity's Animator Controller with a set of visual editors. You author states, transitions, blends, masks, events, clips and sequences in dedicated tools that feel like a video editor - drop things on tracks, scrub, preview, tweak. Under the hood it builds and drives its own PlayableGraph (the standard Unity Animator stays on the object with its Controller slot empty), with an allocation-free evaluation loop.

It drives anything with an Animator - characters and creatures, but also weapons, vehicles, machines, doors, cameras and props. Characters are the hard case it's built for; a door or a turret is trivial next to that.

In practice the animator does the graph and the programmer writes gameplay code. That's the whole division of labour.

Table of contents

• Minimal code, by design
• The Honami Timeline
• The node graph
• Sub-Nodes
• Transitions
• Parameters
• Weighted, per-bone masks
• The event system
• Reuse: override controllers & inheritance
• The Linked Brain
• The Clip Player
• Built-in rig system
• Performance
• Scripting API
• Honami vs. the built-in Animator
• Honest scope
• Migrating from Mecanim
• Roadmap

Minimal code, by design

Almost everything lives in the editors, no scripting required:

• States, transitions and layers - drawn in the node graph.
• Blend trees - built in a visual editor with live per-motion weights and a skeleton preview.
• Masks - painted per bone with 0-1 weights in the mask editor.
• Events - wired straight to UnityEvents in the inspector.
• Parameter changes - states can set parameters on enter/exit, right in the graph.
• Clips & sequences - keyed and arranged in the Timeline.

Code shows up in one place: gameplay. You push values in, and you handle a few callbacks:

using HonamiAnimationSystem.Runtime.Core;
using UnityEngine;

public sealed class PlayerAnimation : MonoBehaviour
{
    private HonamiAnimator _honami;
    private static readonly int Speed = HonamiAnimator.StringToHash("Speed");

    private void Awake() => TryGetComponent(out _honami);

    private void OnEnable()  => _honami.OnStateFinished += OnFinished;
    private void OnDisable() => _honami.OnStateFinished -= OnFinished;

    private void Update()
    {
        // Everything above was authored in the UI. This is the code you actually write:
        _honami.SetFloat(Speed, _velocity.magnitude);           // drive a blend tree
        if (_jumpPressed) _honami.PlayState("Jump");            // trigger a state
        if (_firePressed) _honami.PlayState("Fire", layer: 1);  // upper-body layer
    }

    private void OnFinished(string state)
    {
        if (state == "Reload") _weapon.FillMagazine();
    }
}

Most integrations aren't much bigger than this. Cache the animator, push a few parameters, handle a couple of callbacks. You never end up re-implementing the state machine in C#.

The Honami Timeline

Everything is authored the way you'd edit video: a tabbed timeline window with a frame ruler, tracks, a scrub head and a transport bar. Open as many tabs as you want - a state here, a clip there, a whole sequence beside them - and switch between them like browser tabs. Each tab keeps its own selection and view. It does three things:

State mode - author and preview a state

Drop clips on the animation track, place Local and Global event markers exactly where they should fire, and tune Loop, Speed and Reversed in the properties panel. The track adapts to the node type - a single clip, a random set, a sequencer's segments, or a blend tree's motions.

Press Preview and it plays right in the Scene view, with no Play Mode and no compile wait. This isn't a rough clip sample: avatar masks (with their per-bone weights), blend trees, mirroring, constraints and bone replacements are all applied, so it matches what runs in-game. Turn on preview for several states across different layers and they composite in the correct order, lower layers first.

Clip mode - a keyframe editor inside Honami

Need to fix a clip? Don't leave for Unity's Animation window. Clip mode is a per-bone dopesheet: scrub to a frame, move a bone in the Scene, and Honami records the keyframe straight into the AnimationClip. Curves, keys and per-bone rotation/position tracks all live in the same timeline UI. Clips embedded in an FBX open read-only, so a source asset is never corrupted by accident.

Sequencer mode (Director) - scripted sequences

In development - arrange clips and events on tracks, with runtime playback via HonamiDirector. Full cinematic tooling is coming.

The node graph

You draw states, transitions and layers instead of writing them. Behaviour is split across typed nodes rather than one giant flat state machine, which is what keeps the graph readable as it grows:

• Animation Node - plays a single clip, with a trimmable start/end range.
• Blend Tree Node - the smooth locomotion blend: flows continuously between clips like idle → walk → run along a float such as speed, with no visible transition. Standard mode speed-syncs the clips so footfalls stay in phase; Simple plays each at its own speed. Damped, so it eases instead of snapping.
• Random Node - picks one weighted clip on entry for idle/attack variety; can even sync its pick across linked animators.
• Sequencer Node - stitches several clips onto one state's timeline (wind-up → hit → recover) without extra transitions.
• Event Node - a state with no animation at all: a pure logic beat that fires event markers, sets parameters and runs Sub-Nodes for a set duration. Chain a few with exit-time transitions for scripted sequences, timers and decision points - all authored in the UI, no code.
• Portal Nodes - named entrance/exit pairs that "teleport" the flow across a big graph without long messy wires; virtual, zero runtime cost, with optional source filtering.
• Any State / Repeater - global transitions reachable from anywhere (deaths, stuns); the Repeater force-restarts its target for mash-friendly hit reactions with a cooldown and repeat cap. Combo Mode turns it into a melee combo driver: fires go through the outgoing transitions in order, and presses landing before the current attack's cancel window are buffered instead of interrupting it.

Sub-Nodes

Sub-Nodes attach logic inside a state so the main graph stays about high-level flow. They are plain ScriptableObject assets (HonamiSubNodeBase) with an OnEnter / UpdateRuntime / OnExit lifecycle, and they only run while their state is active. Stack as many as you want on a state. Built-ins include:

• Mask Switcher - swap or blend the avatar mask from parameter conditions (first matching rule wins), e.g. dual-wielding or directional hit masks.
• Replacer - apply bone replacements for the duration of the state.
• Smooth Bone Weight - ease per-bone mask weights in and out instead of snapping.
• Jitter Speed / Jitter Weight - organic per-frame variation of playback speed or state weight.
• Log - a debugging probe that prints on enter/update/exit.

Writing your own is just subclassing HonamiSubNodeBase and overriding UpdateRuntime (plus optional OnEnter/OnExit).

Transitions

Transitions are more than a duration and a condition. Each one has a type, a priority, interruption rules, and can even write parameters when it fires:

• Standard - classic cross-fade, linear, eased or curve-driven.
• Victim - one side of the blend is the "victim": its speed can be multiplied and its weight can drop on a custom or quadratic curve. Perfect for snappy attack cancels that don't pop.
• Smart - adaptive duration that scales with the time left in the current state (short remainder, short blend).

Every cross-fade can be shaped with an Easing preset - the full Penner set familiar from tweening libraries like PrimeTween or DOTween (Sine, Quad, Cubic, Quart, Quint, Expo, Circ, Back, Elastic, Bounce, each as In / Out / In-Out), with Back and Elastic genuinely overshooting past the target pose - or with a hand-drawn custom curve. Freeze Mode keeps fast transitions readable: Destination holds the target on its first frame during the blend and starts playing only when the transition completes (crisp attack wind-ups), Source freezes the state being left on its current pose so it fades out static.

Add priority (higher can interrupt lower even when Can Interrupt is off), Sacrifice Existing (instantly kill other blends on the layer), Has Exit Time, Can Transition To Self, a Destination Start Time offset, and per-transition parameter assignments. Conditions combine with AND (draw a second transition for OR) and support If / IfNot / Greater / Less / Equals / NotEqual. Triggers are only consumed when a transition actually fires.

Parameters

Parameters are the variables of your state machine - transitions read them, blend trees sample them, states can write them back. Types: Float, Int, Bool, Trigger, and Random (a float that reseeds itself 0-1 every tick, for code-free idle variety). Storage is backed by native arrays for fast, allocation-free access, and every setter/getter has a string and an int-hash overload - cache the hash once and use it in hot paths. States (and transitions) can also assign parameters on enter/exit from the graph, so simple bookkeeping like an InCombat flag needs no code at all.

Weighted, per-bone masks

Unity Avatar Masks are on/off - a bone is in the mask or it isn't. Honami masks carry a weight from 0 to 1 for every bone, painted in a dedicated mask editor. An upper-body layer can bleed into the spine at 40%, a hit reaction can fade across the torso instead of snapping on, and a partial mask can soften the seam between layers. Masks are bone-path based (an excludeUnlisted toggle chooses whether unlisted bones pass through or are blocked), so they work on any skeleton, with no Humanoid Avatar and none of its 15-bone minimum.

The event system

Unity bakes Animation Events into the AnimationClip, which couples every clip to a specific method on a specific GameObject and means a shared clip can only ever fire the same event. Honami puts event markers on the state instead. The same clip fires different events in different states, and your .anim files stay clean and reusable. Two independent channels:

• Local Event - invokes UnityEvent actions on a HonamiLocalEventReceiver next to the animator. Wire it up in the inspector; no code required.
• Global Event - dispatches to reusable HonamiGlobalEvent components you subclass in C#, living on any GameObject in the scene (e.g. a FootstepEvent shared across every character, or a door the animation opens remotely).

Markers behave sensibly: they re-fire each loop, fire in reverse on reversed states, don't fire on paused states or layers, and can be cancelled when a state is skipped. Separately, HonamiAnimator also raises C# events - OnStateEntered, OnStateFinished, and OnStateExited (with a full HonamiStateExitInfo telling you exactly why a state ended and what replaced it).

Reuse: override controllers & inheritance

Unity's AnimatorOverrideController mostly swaps clips. Honami's Override Controllers inherit an entire controller - its layers, parameters and states appear as virtual inherited states - and then let you override just what differs: replace a node, retune a transition, or add a local layer. Character variants (a heavy vs. a light enemy, a rifle vs. a pistol loadout) reuse one authored graph instead of a copy-pasted forest of controllers.

The Linked Brain

Coordinate many animators from one place. The Linked Brain broadcasts a state change, a parameter, or an action to whole groups at once, filtered by target mode - AllLinked, ChildrenOnly, or ByTag (tags are HonamiTagID assets, so renames never break references). Author the same broadcasts visually in the Brain graph.

For decentralized, world-space coordination there's also the static HonamiLinkedAction - animators whose states carry an ActionID register themselves automatically, and a single call fans the reaction out with real spatial targeting:

• PlayGlobal - everyone registered (optional cap).
• PlayByTag / PlayByLayer / PlayInHierarchy - filtered groups.
• PlayNearby - everyone within a radius.
• PlayClosest - the N nearest.
• PlayPropagated - a shockwave: reactions ripple outward, delayed by distance ÷ speed.

So you can drive a whole squad's reactions without looping over animators in gameplay code.

The Clip Player

Not everything needs a state machine, and that has nothing to do with how important the object is. Most NPCs never needed one: their idle, walk, talk and two reactions are already chosen by a behaviour tree, a dialogue system or a spawner, so wrapping that in a controller graph just means authoring the same decision twice. The same goes for creatures, background crowds, machines and doors.

HonamiClipPlayer is the Honami runtime with the graph taken out. Nodes, transitions, conditions, exit times, parameters, blend trees, sub-nodes and masks aren't missing from it - they were removed on purpose, because that machinery is something you author, debug and maintain in order to express a decision your code had already made. What's left is the part that actually produces the animation: clips, weights, crossfades, layers and wrap modes, on a list that lives on the object itself. It's what Unity's old Animation component was, rebuilt on the same PlayableGraph core:

_player.CrossFade("Walk", 0.25f);      // blended
_player.PlayClip("Flinch");            // snap, on its own layer
_player.PlayQueued("Idle");            // after the one-shot ends
_player.Blend("Breathe", 0.4f, 0.5f);  // layered on top
_player.Sample("Aim", pitch01);        // pose one frame, no playback
_player["Walk"].Speed = 1.5f;          // live handle, like the legacy AnimationState

Per clip you author a name, speed, layer and wrap mode, plus an optional ActionID. PlayClip deliberately does not rewind a clip that is already playing, so calling it every frame from movement code is safe.

So the question isn't what the Clip Player is missing, it's what the graph would be buying you. It pays for itself when the behaviour genuinely lives inside it: a 1D locomotion blend between motions, a weighted upper-body mask, an override controller per variant, conditions and exit times an animator should tune without touching code. When none of that is true, every node and transition is ceremony around a call your code was going to make anyway.

Wrap modes decide what "finished" means

Mode	At the end of the clip
Once	Fires OnClipFinished and drops to weight 0 - the clip releases the hierarchy.
ClampForever	Fires OnClipFinished and holds the last frame at full weight.
Loop	Wraps back to the start. Never finishes.
PingPong	Reverses direction at both ends. Never finishes.

That distinction does real work: a door that must stay open after its opening animation wants ClampForever, while a one-shot on Once hands the hierarchy back, so whatever sits underneath - or the captured initial pose - takes over on its own.

Layers, without masks

All clips feed one mixer. Within a layer, weights normalize when they sum above 1; layers then resolve from the highest down, each consuming what the layers above left over, so a clip at full weight on layer 1 completely covers layer 0. PlayClip and CrossFade only fade out clips on the target's own layer - which means a Once reaction on layer 1 can cover a looping idle on layer 0 and release it at the end, with no transitions authored and no code to put the idle back. There are no avatar masks here: a layer overrides everything under it, not a selected set of bones.

Handles, state and events

The indexer returns a live handle to one clip, the way the legacy AnimationState did - Speed, Weight, CurrentTime, NormalizedTime, WrapMode, IsPlaying and Length, all readable and writable while it plays. Alongside it the player answers CurrentClip, ClipCount, IsPlayingAny, IsPlaying(name), TryGetState, States and Rewind, and raises OnClipStarted / OnClipFinished with the clip name. None of it allocates.

A clip you never play

Sample(name, normalizedTime) pins one clip at a single frame, evaluates once, and stops advancing. Feed it a changing value every frame and an AnimationClip becomes a curve you drive by hand: an NPC's aim pose driven by where it's looking, a head turn tied to a look-at angle, a lever that follows the player's grip, a machine wired to a slider.

A library you can change at runtime

AddClip, RemoveClip and Rebuild edit the clip list while the game runs, which suits objects that are assembled rather than authored - a machine whose animation set depends on the module bolted onto it, a creature that learns a new attack, a prop built from downloaded content. A rebuild replaces the graph, so handles taken before it are gone and nothing is playing until you say so.

Auditioning without Play Mode

Every row in the inspector has a play button. In edit mode it poses the actual scene object, honouring that row's speed and wrap mode; Honami snapshots every local transform first and writes it back on stop, and it never enables Unity's global AnimationMode, so it won't fight an open Timeline or Animation window. In play mode the same button drives the real component through the Preview Fade slider, and the inspector grows a live panel: a weight/time bar per clip, the dominant clip's name, and Stop All / Pause.

A sibling, not a replacement

The cut stopped at the authoring layer. Both components derive from HonamiAnimatorBase, so a Clip Player carries a full Honami rig stack, keeps the initial-pose safety net, evaluates at a capped 15 FPS in the distance, honours every update mode and global weight, and can be ticked by hand with Tick(dt) for deterministic and networked updates. Nothing that affects the animation itself was traded away - only states, transitions, parameters, blend trees and masks, which is the trade you came for. Reach for HonamiAnimator when you actually want one of those back.

It is also a full citizen of the Linked system: a Brain in Childs mode picks up Clip Players alongside animators, and PlayState, ActionIDs, StopAll and GlobalWeight reach them. Parameter and state-machine broadcasts apply only to the controller-backed animators (brain.FullAnimators) and skip Clip Players, which have no parameters to set.

Built-in rig system

Standard Unity rigging needs the external Animation Rigging package - a separate dependency, decoupled from the Animator, with its own GameObject-based setup. Honami includes a rig-agnostic constraint pipeline out of the box. All constraints run as a final correction pass after sampling, so authored animation stays in charge while procedural adjustments handle contacts, aiming, secondary motion and physics.

• Pose Constraint - injects static or dynamic poses into bone hierarchies for actions like a sliding stance, crouch offsets, or holding a weapon, in local or world space with full weight control.
• LookAt Constraint - rotates a bone or a chain toward a target with custom aim/up axes and per-bone weights: heads, eyes, turrets, barrels, creature sensors, long necks. Additive mode layers on top of authored animation without overwriting it.
• Point Constraint - locks a transform to another's position/rotation with authored offsets, keeping sockets, armor plates and held objects aligned without turning them into Humanoid bones.
• Pivot Fixer - solves the "wrong imported pivot" problem for weapon grips, hinges and attachment points by choosing a different effective anchor than the FBX provides.
• Pseudo-Physics - springy inertia and secondary motion for hair, tails, cloth, antennae, cables and weapon sway. It's cheap: a spring approximation, no Rigidbody chains involved.
• Foot IK, Anti-Jitter, Scale Fixer, Space Switcher and Bone Replacer round out the toolkit for planting feet, cleaning noisy motion, fixing scale, switching bone spaces and swapping skeleton parts at runtime.

No external packages, no humanoid limitations, and no per-object rigging setup overhead.

Performance

The core evaluation loop produces zero GC allocations per frame. Parameters live in native arrays with integer-hash lookup, and every API method has a hash overload so hot paths stay allocation-free. Distant characters can evaluate at a fixed 15 or 30 FPS with optional interpolation via the per-animator FPS Cap - a free animation LOD - and standard Unity culling modes are forwarded to the Animator. Off-screen actors can be paused for the cost of one bool check per tick, or frozen in place entirely.

Scripting API

The full runtime API lives on HonamiAnimator in HonamiAnimationSystem.Runtime.Core (HonamiClipPlayer shares everything on the common base - ticking, pausing, time scale, FPS cap, global weight, initial pose, ActionIDs). Every state/parameter method has name, int-hash and (for states) ...ByGuid overloads. Highlights:

• Playback - PlayState, PlayStateByGuidWithPriority, IsStateActive, GetStateProgress, GetTransitionWeight.
• Skipping - TrySkipState / TryAutoSkipState conditionally interrupt a specific state, reusing the transition authored in the graph.
• Pausing / stopping - Pause, PauseLayer, Stop, StopAll, StopAndKeepPose, ResetToDefault.
• Parameters - SetFloat/Int/Bool/Trigger and getters, plus ResetTrigger.
• Events - OnStateEntered, OnStateFinished, OnStateExited.
• Controllers - SetController with an optional cross-fade between old and new graphs.
• Mirroring & time - SetGlobalMirror, TimeScale, FpsCap, and manual Tick(dt) for deterministic or networked updates.
• Clip Player - PlayClip, CrossFade, PlayQueued, Blend, Sample, Stop, Rewind, AddClip / RemoveClip / Rebuild, the player["Idle"] handles, and OnClipStarted / OnClipFinished.

Honami vs. the built-in Animator

Only the areas where the two genuinely diverge - where Mecanim already does the job well, it isn't listed.

Area	Built-in Animator	Honami
Authoring	⚠️ Graph only; previewing behavior means entering Play Mode.	✅ Timeline editors for states, clips and sequences with faithful in-Scene preview.
Underlying engine	⚠️ Closed native Mecanim loop (black box, non-extendable).	✅ Your own C# evaluation stack over a PlayableGraph you can inspect.
Logic style	⚠️ Flat state machines, prone to transition spaghetti.	✅ Modular graphs with typed, custom node types and Sub-Nodes.
Transitions	⚠️ Fixed duration & exit time.	✅ Runtime-parametric: priority interrupts, victim weighting, adaptive duration, easing presets, freeze modes.
Reuse	❌ Override controllers mostly swap clips.	✅ Controller & layer inheritance with virtual states and parameter propagation.
State logic	⚠️ StateMachineBehaviour.	✅ Sub-Nodes (ScriptableObject assets) with OnEnter/Update/OnExit.
Animation events	⚠️ Baked into the clip, coupled to code.	✅ Authored on the state; clips stay clean; Local + Global channels.
Masks	⚠️ Binary - a bone is in or out.	✅ Weighted per-bone masks (0-1 per bone).
Rigging	⚠️ External Animation Rigging package, complex setup.	✅ Built-in rig-agnostic constraint pass, no extra package.
Many characters	❌ No cross-animator coordination.	✅ Linked Brain broadcast by tag, radius, wave or closest-N.
Objects that don't need a graph	⚠️ A controller asset per NPC and per door, or the deprecated legacy Animation component.	✅ Clip Player: a clip list on the object, played by name, on the same runtime and rig stack as everything else.
Debugging	❌ Basic active-state progress bar.	✅ Live node highlighting, weights and transition values.
Blend trees	✅ 1D and 2D blend trees.	⚠️ 1D only (2D on the roadmap).
Retargeting	✅ Humanoid muscle-space retargeting across skeletons.	⚠️ No runtime retargeting - binds by transform path. The Humanoid Baker tool retargets Humanoid clips onto your skeleton offline and bakes them to Generic.

Honest scope

Honami drives any Animator-based object, and it shines on fast, code-driven action games and on complex or exotic rigs. It is not a drop-in Mecanim replacement for every project, though: there's no runtime Humanoid retargeting (marketplace Humanoid clips are supported via the offline Humanoid Baker tool), blend trees are 1D only (no 2D blend space), and overlays use masked layers (additive / aim-offset is on the roadmap). If your project leans on live cross-skeleton retargeting or 2D blendspace locomotion, Unity's built-in Animator is still the better fit.

Migrating from Mecanim

Migration is incremental, not a rewrite. A Honami character and a Mecanim character coexist in the same scene without conflict, so you port one prefab at a time while the rest of the game keeps running - and you can stop halfway and ship like that.

What actually changes on a character

Less than you'd think. The GameObject keeps its standard Unity Animator component exactly as it is - the only edit is emptying the Controller slot - and gains a HonamiAnimator component pointing at a HonamiController asset. That's the whole structural change.

Your rig setup, whatever it is, stays as-is. A Humanoid character keeps its Humanoid import and its Avatar assigned in the Animator; a Generic character keeps its Generic setup; a prop or weapon with no avatar at all needs nothing extra. Honami never asks you to convert a model's rig type in either direction - switching an established model between Humanoid and Generic is exactly the kind of change that breaks avatar references, ragdolls and prefab bindings, and it is not part of the migration. Existing clips survive too: Generic clips play as-is, Humanoid clips go through the baker described below.

The migration tools

Everything lives under Window ▸ Honami ▸ Tools:

Animator Converter - right-click any AnimatorController and choose Convert to Honami Controller (or open the window and pick one). It generates a HonamiController with your parameters and their defaults, layers with weights, every state (speed, loop, graph positions preserved), sub-state machines (each gets its own Any State and Exit), and transitions with their conditions, exit times and interruption settings. Two things don't auto-port and the converter says so: 2D blend trees are flattened into a 1D motion list (re-author them as 1D trees, states or layers), and StateMachineBehaviours have no direct equivalent - recreate them as Sub-Nodes, which is usually less code.

Script API Converter - scans a folder for C# scripts that use the Animator API, lists the affected files, and lets you convert the ones you tick. It finds your Animator fields and variables and rewrites them in place: type references (Animator, GetComponent<Animator>, typeof(Animator)) become HonamiAnimator, and Play / CrossFade / CrossFadeInFixedTime become PlayState. Parameter calls like SetFloat, SetBool and SetTrigger are left alone on purpose - HonamiAnimator uses the same method names, so they compile as-is. Converted files also get using HonamiAnimationSystem.Runtime.Core; inserted automatically. It's a source-code rewrite, so commit first and review the diff after.

Humanoid Baker - converts your Humanoid clip library (including marketplace packs and Mixamo) into Generic clips authored for your skeleton. One offline pass per skeleton; the character itself stays Humanoid. See Honest scope for why Honami plays transform-path clips instead of retargeting at runtime.

Project Validator - after the move, finds missing references and broken transitions across your Honami assets.

Step by step, per situation

A Humanoid character coming off Mecanim:

1. Convert its AnimatorController with the Animator Converter; re-author 2D trees and behaviours.
2. Add HonamiAnimator to the prefab, assign the new HonamiController, clear the Animator's Controller slot - Avatar stays.
3. Bake the Humanoid clips with the Humanoid Baker and drop the baked clips into the converted states.
4. Run the Script API Converter over that character's scripts.
5. Check with the Project Validator, then compare behaviour side by side - live node highlighting and transition weights make differences obvious.

A Generic / custom-skeleton character (creatures, weapons, props): same as above minus the baking - Generic clips already bind by transform path, so steps 1, 2, 4, 5 and you're done.

A whole project, gradually: migrate prefab by prefab in whatever order hurts least - Honami and Mecanim characters run side by side indefinitely. Shared scripts that touch many characters are the one thing to plan around: convert them last, or keep a thin wrapper during the transition. Delete the old AnimatorControllers only after the ported characters have proven themselves in play.

Roadmap

Honami is in active beta. In progress and planned:

• Cinematic Director - clip-to-clip blending, camera tracks and full cutscene tooling on top of the current sequencer.
• 2D blend trees - a full 2D blend space alongside the current 1D trees.
• Additive - additive layers for recoil, lean and look/aim overlays.
• Inertialization - velocity-preserving transition blending.

Used in production

Honami powers all animation in Daisen - a fast-paced action game built by LOYAL Studio.

Screenshots

Installation

Via Unity Package Manager (Git URL) (recommended)

1. Open Window → Package Manager.
2. Click the ＋ button → Add package from git URL…
3. Paste:

   https://github.com/loyal-studio/Honami-Animation-System.git
   

4. Click Add and wait for import to complete.
5. The Welcome to Honami window will open automatically on first launch.

Documentation

Open Window → Honami → Documentation directly inside Unity. The built-in docs cover graph authoring, transitions, blend trees, avatars and masks, IK and constraints, the Linked Brain system, the workflow tools (including the Humanoid Baker), the full scripting API and the optimization guide - with live code examples you can copy with one click.

Contributing

Contributions, bug reports and feature requests are welcome!

License

This project is licensed under the MIT License - see LICENSE for details.

Made with Love by LOYAL Studio