Prerecorded, live, or conversational avatar: choose the experience

Choose how the character responds

Separate four layers: what the character can say, who decides the answer, how it is animated, and where it appears. A figure on a display is still a two-dimensional image; transparent screens and projection need a separate optical assessment. They do not imply volumetric capture or a hologram.

A performer may control a character using animation triggers or tracking; face and body capture are additional choices. In Unreal, Live Link receives animation data: by itself, it does not carry the finished picture to the screen. Voice also needs its own path and timing adjustment.

If staffing or connectivity cannot support unexpected situations, start with approved messages and assisted operation. An agent needs interruption rules, an unknown-answer response, and human handoff. No mode guarantees zero delay. Confirm equipment, licenses, content, and responsibilities when defining the project.

Prerecorded video: welcome, guide, and return to idle

1. Idle
2. Message selection
3. Approved clip
4. Closing and return

A recorded character can welcome visitors, explain a route, and offer choices through approved clips. A language or topic selection can trigger the corresponding piece. Interaction selects available material: the character does not listen or improvise answers.

• Prepare a clip list by message and language, with stable name, approved version, actual duration, framing, and destination. The ending should allow a return to idle without a confusing narrative cut.
• Deliver reviewed voice and text, captions, and a visible alternative for information that relies on audio. Confirm character, performance, voice, and music rights.
• Define whether a new action is ignored, queued, or interrupts the clip. Avoid repeated language changes that mix messages.
• Provide a manual trigger for the host and a local idle piece. Automatic detection can fail without making the welcome unusable.

A proposed flow is idle → selection → playback → closing → idle. If a visitor leaves early, decide whether to finish the message or transition back. The operator has a known return command. Prepare these states in the selected playback software and check playback using that application’s guide.

Proposed rehearsal: review every language from the listening and viewing position, check that the message starts in time for the visitor, and repeat inputs during playback. Test the file in the final chain: an extension does not confirm compatible resolution, audio, color, or transparency. Keep the approved video as a local fallback resource.

Live character: separate performance and technical operation

1. Performer: voice + control
2. Animation / rig
3. Engine → picture
4. Audience → performer return

A performer can speak through the character and adapt to the situation. The audience should understand that they are interacting with an animated representation. Assign responsibility for the performance and for keeping the system running; staffing depends on the project scope.

• Voice: performer microphone, agreed processing, and listening destination. Test intelligibility with lip animation, without duplicate voice monitoring.
• Animation: manual triggers, facial capture, or body capture as needed. Identify the application, plugins, version, rig, and route into the render.
• Return: the performer needs to hear the participant and see what is needed to respond. Agree on the audience camera and whether the character view has a separate monitor.
• Hosting: host, languages, allowed topics, turns, breaks, and a signal for handing off to another person or recorded content.

Proposed chain: performer voice and controls feed separate audio and animation paths; the engine renders a picture; output reaches the surface. Audience return travels back to the performer. Drawing these separately avoids confusing a reference camera with animation data.

Proposed rehearsal: a short phrase, an interruption, and a longer answer. Observe lips, audio, and movement at the final destination, not only on the work monitor. If tracking fails, switch to idle pose or approved animation and inform the performer; if voice fails, hand conversation to the host. Do not leave a face frozen in an inappropriate expression.

Facial capture and Live Link: distinguish data from picture

In Live Link, a source provides streams called subjects; roles describe the data type. These are animation data, not a finished camera picture. Reception must be bound to the character and then rendered.

To assess facial capture with Live Link Face, identify the exact phone/tablet, OS, app version, Unreal/MetaHuman version, and working mode. Epic requires the app to stay active in the foreground. The reviewed page limits Android real-time facial tracking to Snapdragon 8 Gen 1 or later; that does not confirm every device/build combination.

• Animation data to coordinate: expected subject name, role, target rig, and owner of data adaptation. Keep a neutral-face reference and the intended range of expressions.
• Voice path: input, performer monitoring, and audience delivery. Record visible face delay and voice delay separately.
• Status: show the operator recent receipt and validity along with connection. If information stops, define an idle pose and recovery before returning to the audience.
• Proposed rehearsal: front-facing expression, intended head turn, mouth opening, expression change, and simulated loss/recovery. Check the final character, not just the presence of a subject.

Testing needs an authorized performer and defined performance conditions. A demo with simulated inputs can check states and visual adaptation. To check compatibility and facial animation quality, use the intended device and character. Configure video capture and display output as separate stages.

Full body: performance area and retargeting

Separate body capture, character adaptation, and final render. Epic documents retargeting between skeletons through IK Rigs; this adaptation does not prove that a capture system measured movement correctly. Selecting the sensor or suit is a further decision.

• Area: draw the performance volume, boundaries, sensor positions, and objects that may obscure hands, feet, or torso. Record intended lighting and clothing.
• Capture: request manufacturer, model, firmware, software/SDK, OS, and method. Do not apply optical-camera conditions to an inertial system.
• Character: confirm rig, scale, orientation, neutral pose, and apparent hand/foot contact. Human gestures may need adaptation for different character proportions.
• Operation: define a second body entering, performer changes, and partial joint loss. Do not treat an identity jump as continuous tracking of the same participant.

Proposed rehearsal: walk within the area, turn as scripted, cross arms, crouch if required, and leave the volume. Watch for sliding feet, pose jumps, incorrect limb orientation, and reappearance after occlusion. Agree criteria for those movements and that location; do not infer them from an isolated advertised accuracy figure.

If tracking cannot support the intended experience, reduce the movement range, trigger prepared animations, or use a half-body character. Prepare an approved rest pose and transition to avoid visible deformation. Physical testing and equipment availability remain to be confirmed for the project.

Conversational agent: bounded content and human handoff

1. Authorized input
2. Interpretation + sources
3. Answer / voice / figure
4. Operator or host

Generated conversation adds interpretation, response, and presentation stages. An avatar service alone is not an agent that knows the event. Microsoft documents video/voice synthesis and conversational options within its offering; choosing service, region, languages, and terms requires a specific assessment.

• Approved content: prepare questions, reference answers, authorized sources, version, and an owner for schedule/information updates. Define topics the character must hand off.
• Participation: decide between text, a turn button, or a microphone. Show listening, processing, and responding states; offer an option that does not require speaking.
• Boundaries: short answers, unknown-answer handling, interruption, and operator cutoff. A style instruction cannot guarantee every answer is correct.
• Handoff: a visible host handles out-of-scope queries, errors, unavailable languages, and assistance. Provide staff for that handoff when the chosen mode requires it.

Proposed test using fictional text: covered question, missing fact, ambiguous question, interruption, and service loss. Compare answers against approved sources and verify the operator can cut response voice and picture and return to idle. Review pronunciation and timing per language; enabling translation does not establish equivalence.

For a quote, identify integration, metered services, concurrency, support, and local fallback content. Confirm licensing and data handling before contracting; avoid retaining audience voice when unnecessary. Use fictional characters or authorized assets and disclose their synthetic nature.