Parametric generation: FLAME, Anny and the topology contract

The strongest implemented generation path in Avashi was constrained and parametric. Instead of asking a model to invent arbitrary topology, it combined a template with identity and expression bases. This made vertex correspondence predictable, which is valuable when the same asset must blink, speak and express emotion.

The inspected FLAME service loaded 5,023 vertices, 9,976 faces, 300 identity components and 100 expression components. These are concrete dimensions from the implementation and saved prototype output. They describe the face model used in this path, not the complexity of every imported avatar.

What the implemented forward pass did

The face was assembled as a template plus two linear combinations:

vertices = template
         + identity_basis × identity_coefficients
         + expression_basis × expression_coefficients

The service used NumPy contractions rather than a neural-network serving process. Its forward method explicitly covered shape and expression only, without the complete pose-dependent FLAME path. Loading a joint regressor did not mean jaw rotation, skinning and pose correctives had all been implemented.

This distinction affects both performance and correctness. A linear face deformation can be inexpensive on a CPU, but it does not prove a fully rigged digital human has been generated. The rig, eyes, teeth, mouth interior, textures and body still have to satisfy their own contracts.

The resource calculation

For 5,023 vertices, three coordinates and 400 basis directions, a dense float32 basis occupies:

5,023 × 3 × 400 × 4 bytes = 24,110,400 bytes ≈ 22.99 MiB

A single set of vertex positions occupies 60,276 bytes. Keeping loaded bases in a process-level cache is therefore more sensible than reparsing the model for every avatar. Concurrent workers may each hold their own copy, so worker count still affects host memory.

The calculation does not include Python overhead, normals, intermediate arrays or assets. It is a resource estimate from array dimensions, not a measured request-latency result. A production API should benchmark warm and cold requests separately and avoid blocking an asynchronous event loop with long synchronous work.

Why 52 names did not solve facial calibration

Avashi’s blendshape service defined 52 ARKit-style names and mapped each to a handcrafted sparse vector in FLAME expression space. It evaluated the expression direction and subtracted the neutral mesh to produce a displacement field.

This supplied a consistent experimental interface. It did not establish semantic independence or anatomical accuracy. PCA directions are ordered by statistical variation; a direction is not automatically a clean “left blink” or “tongue out” actuator.

Calibration should test locality and intent. A left-eye control should not close both eyes equally. A smile should not collapse the teeth region. A jaw-open control should provide usable articulation rather than stretching the entire lower face. Extreme combinations must also be inspected, because individually acceptable morphs can collide when added.

A useful automated check measures non-finite values, extreme displacement, left/right symmetry and region leakage. Human review remains necessary for whether the motion looks correct. A standard name is an interface promise, not its proof.

Anny addressed a different layer

The repository included Anny exploration and a staged body-integration prototype. A body model broadens the available shape and pose space, but joining its output to a FLAME head still requires scale alignment, compatible neck boundaries, normals, skin weights and materials.

The current upstream Anny project provides a differentiable human-body model and has changed its rig and topology APIs over time. A historical notebook should remain attached to its installed version; a current example is not automatically a drop-in replacement. Anny source and version history

A sensible merge experiment freezes both model versions, identifies a neck correspondence, fits alignment with landmarks and inspects the seam under motion. Simply concatenating vertex arrays creates two surfaces, not a coherent animated body.

Text parameters are a control interface

The text-to-parameter stage should return a bounded specification, not unrestricted coefficients. A request such as “a stylized adult guide with a rounder face” needs an explicit mapping to permitted controls and a preview for review.

Avoid treating broad demographic labels as precise anatomy or skin-color rules. The prototype’s appearance presets are implementation choices, not a validated model of human populations. User-editable visual controls and reference-based review provide a better product contract than asserting a deterministic appearance from identity labels.

A reusable parameter record should include units, ranges, seed, model version and the resulting asset hash. Persist the resolved values, because the same natural-language prompt may map differently after the translator changes.

Export is the next acceptance boundary

The output contract needs positions, normals, indices, materials and morph targets whose vertex ordering agrees with the neutral mesh. If the pipeline reorders or simplifies vertices, it must transform every dependent target and skinning attribute consistently.

The inspected export path also included optional skeleton and VRM metadata. An extension declaration should be validated against the actual asset. It cannot compensate for an invalid hierarchy or missing facial deformation.

The practical result of this path was a predictable research foundation. Its limits were equally important: constrained face generation and approximate expression mapping are meaningful work, but they do not establish arbitrary, production-ready character generation.