Avashi

Status: experimental research project, now closed. A client commissioned Avashi to investigate an internal, Meshy-like avatar-generation product. The ambition extended beyond generating a static asset: the character should animate, converse through text and voice, and remember relevant context across interactions.

The work produced generation prototypes, asset experiments, animation libraries, playgrounds and conversational integrations. The rendered experience was too heavy for the intended mobile use. Continuing to improve asset quality, runtime performance and product completeness required more investment than the available budget allowed, and the engagement closed.

This case study describes the research and its limits. It does not present Avashi as a currently developing product or a completed replacement for a general-purpose 3D-generation service.

The brief and the engineering problem

“Generate an avatar” contains several separate problems. A model can create an attractive shape without producing topology that deforms correctly. A rigged asset can animate in a desktop preview while loading slowly on a phone. A conversational agent can respond quickly while the character’s mouth follows a different clock.

The client’s brief therefore became a connected research programme: create or adapt the character, normalize its animation controls, render it interactively, connect conversation events to expressions and speech, and preserve useful memory. Each layer needed to work without assuming the previous one had solved everything.

Approaches we explored

The approaches were alternatives and experiments at different levels of maturity. The repository does not establish that every researched model was deployed or that every branch formed one completed end-to-end pipeline.

What we built at the generation layer

The FLAME service loaded a mesh with 5,023 vertices, 9,976 faces, 300 identity components and 100 expression components. Its implemented forward pass combined identity and expression offsets using NumPy. It did not implement the full pose-dependent FLAME deformation path.

A separate service generated 52 named ARKit-style morph targets through a handcrafted mapping into the expression basis. This created a consistent interface for experiments. Naming a target jawOpen or eyeBlinkLeft did not establish that its deformation was anatomically calibrated; that required visual and geometric checks.

The export work connected geometry, normals, colors, morph targets and optional skeleton/VRM metadata. The runtime and playgrounds then made those assets inspectable. This was a practical way to find where an apparently valid file still failed the experience: a jaw moved incorrectly, a material rendered differently, or an imported avatar lacked the expected controls.

Animation and conversational behavior

The animation work separated idle motion, blinking, gaze, emotion and speech. ADSR envelopes controlled how expressions rose, held and faded. Visemes supplied mouth-shape cues. Layering mattered because a speaking mouth and an emotional expression can attempt to drive the same controls.

On top of the visual layer, the conversation services included streaming text, emotion events, bounded tool loops and voice pipelines. The inspected voice path used Pipecat with LiveKit transport, configurable recognition and synthesis, voice-activity detection and interruption handling.

The architecture connected these systems through session and message identities. A text token, a spoken sentence and a facial cue could then belong to the same response, while cancellation had a way to invalidate obsolete work.

Memory was a service boundary

The surrounding deployment tree included a separate memory service and conversational clients. The code combined document storage, vector retrieval, cached context and graph-based integration paths. It also contained prefetch and channel-sensitive routing for voice latency.

The important distinction was between recent conversation history and longer-lived memory. A user preference, an episode summary and a time-dependent fact should not be treated as interchangeable strings. Memory needed identity scope, provenance, freshness and a way to handle correction.

The article series examines both the implemented paths and the gaps visible in them, including optional avatar scope in an older service and the consistency problems created when a document write succeeds but its vector projection fails.

Why mobile became the limiting constraint

A September 2026 inspection of retained local files found substantial variation:

These are file measurements, not phone frame-rate results. The two stylized variants retained the same summed position-accessor count of 43,988, despite the smaller file and reduced morph-target count. A smaller download did not mean that all rendering work had disappeared.

The runtime also incurred texture decoding, geometry upload, skinning, morph evaluation, materials, lighting and audio/UI work. Some viewers used device-pixel ratios up to two and enabled antialiasing; the shared canvas defaulted to shadows. These choices made sense for inspecting quality, but a phone needed a deliberately smaller rendering budget.

My contribution

As architect and lead, I connected the client’s product ambition to the generation, animation and conversational work. The contribution included evaluating alternative avatar representations, shaping the generation/export and runtime boundaries, and connecting text, voice and memory to the visual experience.

The work also involved judging feasibility across layers. A good-looking demo could not stand in for a mobile acceptance result, and a reusable rendering library could not settle the economics of a general-purpose avatar platform.

Outcome and what would change in a restart

Avashi remained an experimental client research engagement. The mobile experience was too heavy, and budgetary constraints led to closure. The reusable output is the engineering knowledge: generation and animation contracts, inspected assets, conversational integration patterns and a clearer account of where product feasibility broke down.

A restart should select one representation and one target device class before expanding generation scope. It should fund a complete acceptance slice—load, converse, interrupt, recall context and recover—then measure sustained behavior on real phones. That would make the next investment decision depend on product evidence rather than another impressive desktop render.

Read the eight-part Avashi research series, covering generation approaches, animation, text and voice, memory, mobile performance and research closure.