Part 1 of 8 · 5 min read
An internal avatar platform: the research brief and the approach map
The client brief, five engineering contracts, the explored approaches and why Avashi remained experimental.
Arunank Sharan · Kuzushi Labs ·
In this article
Avashi began as client-commissioned research into an internal, Meshy-like generation product. The intended output was a character that could be used in an interactive experience: generated or adapted appearance, expressive animation, text and voice conversation, and memory across sessions. The rendered version proved too heavy for mobile phones, and budgetary constraints eventually closed the engagement.
That outcome belongs in the technical account. A research project is useful when it turns uncertain product claims into concrete constraints, including evidence that the next stage costs more than the available investment.
Separate the five contracts
A character product has at least five contracts. The generation contract describes the asset we can produce. The animation contract describes its controllable bones and morphs. The rendering contract describes the devices that can display it. The conversation contract describes turns, speech and interruption. The memory contract describes what persists and who can retrieve it.
These contracts can fail independently. A beautiful head without a useful mouth interior may fail speech animation. A well-rigged avatar with large textures may fail startup time. An expressive character connected to the wrong user’s memories fails the product even when its frame rate is excellent.
The resulting architecture should allow us to replace one representation without rewriting the conversation service. It should also prevent presentation from becoming the authority on conversation state: a “speaking” animation does not prove audio has started playing.
What we actually explored
The repository contains several paths with different evidence:
| Path | Evidence inspected | What it can establish |
|---|---|---|
| FLAME | Generation service, blendshape mapping, export code and prototype notebook outputs | A constrained face-generation implementation |
| Anny | Interactive notebook and staged pipeline prototype | Body-model exploration and integration work |
| Blender / MPFB | Detailed workflows, scripts and experimental GLB exports | An authoring route with control over mesh and rig |
| Imported avatars | GLB/VRM assets, analysis tools and viewers | Runtime experimentation on existing character assets |
| Live2D | Cubism/PixiJS playground and expression/motion modules | A distinct 2D representation path |
| Diffusion, reconstruction and neural rendering | Research notes and external references | An evaluated design landscape, not proof of deployment |
The notebook inventory itself is revealing. The mesh-fundamentals notebook retained outputs in 18 code cells and the pipeline prototype in 11. The separate FLAME and Anny interactive notebooks had no saved output cells in the inspected snapshot. A notebook’s existence is evidence of authored experimentation; it is not a benchmark result.
Why a Meshy-like brief needed a narrower first product
“Text to 3D” can mean producing a visually plausible object, a textured mesh, a character with a skeleton, or a face with reliable speech controls. Each successive output requires additional information and validation.
For Avashi, a constrained character family offered a more tractable first contract than arbitrary topology. If every face shared a vertex layout, expression deltas could be defined consistently. Imported characters offered faster visual variation but introduced differences in naming, scale, materials, skeletons and facial controls.
This is why the generation model could not be selected from image quality alone. The relevant comparison was the total work to reach an accepted interactive character, including cleanup, rigging, optimization and runtime integration.
Three useful experiments
A generation experiment varies appearance parameters while keeping topology fixed. It asks whether the output is stable, controllable and exportable.
An animation experiment keeps the asset fixed while varying emotion, speech and gaze. It asks whether the controls produce the intended behavior without collisions.
A product experiment keeps a complete configuration fixed and runs a realistic session on the target phone. It includes asset loading, conversation, interruption, memory retrieval and sustained rendering. It asks whether the system is usable as a whole.
Mixing these experiments makes diagnosis difficult. If asset, renderer, prompt and speech provider all change between demonstrations, an apparent improvement has no clear cause.
A practical research record
The publication’s reference research record uses an experiment ID, asset hash, generator revision, rig schema, renderer profile, conversation configuration and device description. Record observed results alongside the acceptance rule and the next decision.
A failed mobile trial should retain its reason: download delay, decode stall, graphics memory pressure, frame-time spikes, thermal degradation or audio contention. “Mobile was slow” is an honest summary of the outcome, but it is not enough to choose the next optimization.
The retained source supports several of these mechanisms. It does not provide a standardized device benchmark, so this series does not invent phone-specific frame rates or a universal 60 fps achievement.
My contribution and the delivery lesson
My role connected the client brief with the avatar-generation, animation and conversational architecture. The useful engineering decision was to keep the layers visible enough to evaluate separately while still asking whether they produced one acceptable experience.
The programme closed under its budget constraints. A restart would begin with a target device, a narrow character family and one complete interaction, then expand only after that slice met its acceptance conditions. The rest of this series develops the technical work behind that decision.