How brewery staff
learned to walk

01 · The problem

More than translating an image

Staff movements are connected to production: brewers approach the brewing equipment, the operator goes to the packaging line and the technologist moves to the recipe-refinement work area. A changed assignment needs a new route; after work, the employee returns to a waiting position.

The early version used separate drawn poses. Alternating two leg poses and mirroring the figure suggested movement, but did not produce a complete gait. Walking away into the workshop could still show the front of the person, while translation did not consistently match the stride. More similar poses were not enough: the whole body needed a coherent cycle.

02 · Motion source

The skeleton supplies motion, the drawing supplies identity

The shared neutral gait uses Walk_Loop from the Quaternius Universal Animation Library, licensed CC0. The source cycle lasts about 1.333 seconds. Legs, hips, torso and arms move together rather than being assembled from unrelated limb positions.

A separate Three.js viewer renders the motion on a mannequin through a fixed orthographic camera. The model is rotated in 45-degree increments to produce eight views. The mannequin walks in place: horizontal hip translation is removed from the image because the game controls the employee’s position on the workshop floor.

The mannequin is not the employee’s visual identity. It supplies a motion video and reference geometry for grounding. Appearance comes from the original drawing of each employee: the brewer in an apron, the operator, Marta and the technologist in a lab coat.

03 · Motion transfer

Wan Animate 2 combines the two inputs

The network receives a character image and a driving video of the gait. This project uses Wan Animate 2: the Comfy-Org/Wan-Animate-2 package based on Wan2.2-Animate-2-14B, with int8 convrot weights and a LightX2V LoRA. The graph runs in ComfyUI 0.41.3 on AIserver with an RTX PRO 6000.

The final neutral gait uses one driving video per view: 97 frames at 480 × 832 pixels and 24 fps. The same set of motion videos serves all four employees, but each has a different reference image. The model creates the character’s appearance in motion; it does not decide where to go or what job to do.

Other gaits and transfer approaches were explored separately. The integrated technologist is the original Olga, not a donor character redressed to resemble her. A shared neutral gait does not mean shared faces, clothing or roles.

04 · Asset preparation

From video to a frame atlas

A generated video is not yet a game asset. It has a background, its opening differs from steady walking, and frames need a consistent relationship to the floor. One cycle is therefore sampled from the middle: frames 32, 34, …, 62, giving 16 gait phases per view.

The grey background is removed using colour difference and connection to the image border, with a soft transparency edge. Every frame is placed in a 192 × 256 pixel cell using one fixed affine mapping. Snapping the lowest opaque pixel to the floor separately in every frame would move the whole body whenever a foot lifts.

The resulting PNG atlas is 3072 × 2048 pixels: eight direction rows and 16 phase columns. PixiJS selects the relevant texture region during play. There is no neural inference at this stage: the frames have already been prepared.

05 · Runtime movement

The frame follows distance travelled

Running a leg animation on a timer while moving the figure independently produces sliding. Here, the walking phase advances by the screen distance covered divided by the projected cycle length for the displayed view. No translation means no advance through the gait.

Direction follows the current route segment, accounting for the isometric floor. Each of the eight views has its own projected cycle length: lateral motion and movement into depth are foreshortened differently. Screen travel speed therefore also depends on the view.

Cadence and translation are adjusted together. The current shared playback multiplier is 1.794 relative to the source cycle. This changes the visual walk, not brewing time, packaging time or the game clock.

The figure keeps a fixed floor origin. Contact shadows are derived from the driving skeleton’s foot and toe data. They provide a geometric grounding reference, not a physical calculation of contact for every generated shoe pixel.

06 · Routes and work

Routing around equipment without a heavy navigation system

The planner receives rectangular floor footprints for equipment and workshop facilities. It checks a straight route first. If that intersects an obstacle, it considers L-shaped alternatives and detours via one or two offset corner points. It favours less obstacle crossing, then shorter routes with fewer waypoints.

This is a small purpose-built algorithm, not a navigation mesh or A* search. Routes have at most three segments. If none of the candidates is clear, the least-crossing route is used; it would therefore be inaccurate to promise that employees can never pass through equipment. The planner does not provide dynamic employee-to-employee avoidance either.

At the destination, walking gives way to the original waiting or working poses. For these four employees, the new atlas covers walking specifically: separate neural cycles for all work actions have not been integrated. The original pose sheets also provide a fallback if a walking atlas is unavailable.

07 · Results and limits

What this method delivers—and what it does not

Four characters are integrated into the prototype, retaining their individual reference appearances and sharing the structure of a neutral walk. They follow game routes, switch views and return to working or resting poses. This is part of the workshop renderer, not just a standalone video.

Eight views do not amount to continuous three-dimensional turning. A direction change selects another atlas row; there is no smooth 3D turn between them. Background-removal edges can remain visible, and generated frames do not guarantee mathematically exact foot planting. Transitions to the original work poses remain a separate visual limitation.

The approach connects an existing illustrated style to prepared motion without building an individual 3D rig for every employee. The skeleton supplies the stride structure, the network creates the frames, and game code controls the route and display. None of those stages replaces the others.