A realistic model is only the surface. State, audio, expression, animation and resource control make it feel connected to the conversation. This article goes beyond the feature name and looks at the practical customer experience, the engineering trade-offs and the decisions AVRE is using while the product moves from development builds toward a commercial release.
Why AVRE started with a development puppet
The primitive Stage 5 avatar is intentionally not the final AVRE character. It exists to prove the renderer and state architecture. A simple mesh can reveal whether blinking works, idle motion is stable, the camera frames the character correctly and state changes reach the visible scene. If the foundation were built directly around one expensive human model, every animation bug would be mixed with asset complexity.
Once the technical contracts work, the development puppet can be replaced by a detailed human asset without rewriting the chat application. That is the important milestone: art should be replaceable while behaviour remains consistent.
State makes the avatar part of the conversation
An embodied Companion needs to know whether it is idle, listening, thinking, speaking, interrupted or unavailable. Those states should come from real application events, not a visual label that changes independently. For example, microphone capture can trigger Listening; the language model request can trigger Thinking; real audio playback can trigger Speaking.
This state machine also provides a place for animation policy. Listening might use a small attentive pose, Thinking a subtle gaze change, and Speaking a gesture set. The same high-level event can drive different final avatar packs.
Expressions should be structured
AVRE defines development expressions such as neutral, happy, affectionate, amused, concerned, surprised, annoyed and flirtatious. The goal is not to make the final model cycle through exaggerated emoji faces. These are semantic states that a future blendshape system can interpret with subtle intensity.
Hard-coding expression changes by searching chat text for one keyword would be fragile. The dialogue layer has better information about intent and relationship context. Passing structured expression metadata keeps the avatar independent from the exact wording of a response.
Lip sync is not optional glue
If the Companion speaks and the mouth stays still, the 3D layer feels decorative rather than embodied. If the mouth keeps moving after audio stops, the illusion breaks in a different way. Stage 5 therefore tests the audio lifecycle directly: TTS starts, Speaking begins, mouth motion becomes visible; TTS ends or is cancelled, mouth motion stops.
Detailed visemes can come later. The important architectural step is connecting the actual player to the avatar state. That foundation supports both simple amplitude motion and future phoneme-driven facial animation.
The final human avatar needs more than polygons
Commercial quality will require good facial topology, skin, eyes, hair, clothing, facial blendshapes, body rigging and a natural animation library. It will also need variants compatible with the independent identity, presentation and body configuration fields in the Companion profile. The final asset system should not force body configuration to define gender.
Those visual assets can be added in packs if the renderer uses a clean provider boundary. One development avatar is enough for foundation testing; a commercial release needs a curated set with consistent quality and licensing.
Performance is part of realism
A stuttering high-detail avatar is less convincing than a simpler avatar that stays responsive. AVRE runs on the same GPU as the local language model and potentially image generation. The renderer therefore needs frame-rate limits, inactive-window behaviour and adjustable quality. When a heavy image job starts, the application may need to reduce or pause nonessential render work.
The result should be an avatar that feels alive without making the rest of the Companion slower. Resource management is not a background optimisation; it directly affects how natural the character feels.
What this means for AVRE customers
The standard AVRE is aiming for is simple: a customer should be able to understand what a feature does, where the data goes, what hardware it uses and what happens when it fails without reading developer notes. That is why the public site now separates finished behaviour from planned behaviour and why manual testing can reject a technically present feature when the visible workflow is poor. Product documentation will continue to change as the release build becomes more stable, but those changes should make the promises more precise rather than quietly changing what the product is.