--- title: "Directable Digital Actors" date: "2026-08-22" canonical: "https://raytally.com/en/ideas/2026-08-22-wizstar/" generator: "RayTally · dev-prompt-v4" signal: query: "Wizstar" observed_at: "2026-08-22T00:33:15.671Z" sources: - url: "https://www.producthunt.com/products/wizstar" boundary: "Observed at 2026-08-22T00:33:15.671Z." - url: "https://dev.epicgames.com/documentation/metahuman/audio-driven-animation" boundary: "No publication timestamp is present in the source record." - url: "https://opentimelineio.readthedocs.io/en/latest/api/python/opentimelineio.schema.html" boundary: "No publication timestamp is present in the source record." - url: "https://manual.reallusion.com/iclone-8/Content/ENU/8.6/50-Animation/Pro_Facial_Animation/Using-HD-Face-Control-Panel-and-Timeline-Display.htm" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-22-wizstar/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Directable Digital Actors A digital actor that directors can stop during an animated scene, rerun from any beat, and export as editable performance reference. ## Product concept When an indie game director or animation team is blocking a dramatic scene, they can often write the dialogue but struggle to define how a character should pause, evade, or erupt before committing to costly animation production. They import the dialogue, character relationships, and the emotion the scene should convey. Digital actors first perform a complete rough pass, so the team can discuss the performance as if watching a rehearsal rather than guessing from static storyboards. At any beat in playback, the director can say, “Don’t look at him here,” “Hold it in first, then get angry on the next line,” or leave a note by dragging on the timeline. The actor reruns from that beat rather than regenerating the entire scene. Teams can keep several versions side by side and compare how different gazes, breaths, and pauses change the emotional effect of the same line. Once a version is chosen, the product breaks the performance into timecoded references for gaze, expression, pose, and movement. Animators can take those tracks into their existing workflow for further work, while writers can review which line prompted a character action. The review page shows only the important rerun branches, rather than burying the team in an unreadable record of every experiment. The first release is positioned as narrative previs and animation reference, initially covering two-person dialogue and short scenes. It does not generate impersonated performances of real actors, or replace casting or final motion capture. Its purpose is to give directors a rehearsal partner they can stop, restart midway through, and hand off to the production team for further work. ## Why now (backed by facts) When observed on August 22, 2026, Wizstar, which emphasizes professional-actor-style motion performance, ranked 13th in Product Hunt’s new-product feed. This brings the sense of “performance” in digital characters into product discussion and makes it easier for animation teams to ask whether a character can be directed, stopped, and rerun locally. ## Direction (model inference, not independently verified) Target user: The core users are indie game directors, writer-directors, and small animation teams blocking two-person dramatic scenes. It is best used after dialogue is locked but before formal motion capture or keyframe production begins, when performance changes are still inexpensive and the team urgently needs alignment on character motivation, eyelines, and pauses. It also suits remote review, where directors can compare multiple interpretations of the same beat. Minimal entry point: Start by breaking two-person dialogue into timecoded lines, reaction beats, and emotional sections. Facial rough passes can connect to MetaHuman Animator’s audio-driven workflow, whose output can feed Animation Sequence or Level Sequence. For the body, begin with a small, annotated library of standing, turning, evasive, and outburst motion clips rather than attempting open-ended motion generation. Directorial instructions are parsed into gaze targets, movement intensity, delay, and rerun endpoint. Restore character state at the specified beat and recalculate only the subsequent segment. Review notes can use OpenTimelineIO Markers to store time ranges, comments, and version metadata. The first release exports timecode, motion tags, and reference video, without promising direct generation of final skeletal animation. The strongest case against: Language instructions are easily interpreted too literally. One wrong eyeline or pause can make directors spend more time explaining the performance. If rough passes lack breathing, weight shifts, and continuous reactions, version comparisons are meaningless. Local reruns must also preserve pose, emotion, and camera continuity on either side of the change, or the branch point will visibly jump. Character rigs and facial setups differ, so exported tracks need adaptation for each workflow. If generation wait times interrupt the rehearsal rhythm, teams will return to live table reads or hand-animated sketches. Likeness and voice assets must also be restricted to prevent the tool from impersonating real actors. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Find the first users among indie game teams making dialogue-driven narratives. Show three versions of the same line with different pauses and eyelines, so the difference is immediately understandable in a short video. Then offer a downloadable two-person dialogue sample project, allowing animators to test whether its timecodes and motion tags fit their existing workflow. Acquisition content should follow real scene-revision processes, not showcase a beautiful one-off generated character. ## Competitors & gaps (model inference) - MetaHuman Animator: MetaHuman Animator can already generate facial animation from audio, monocular video, or depth data. Its audio workflow also allows adjustment of head movement, blinking, and emotion, with export to Animation Sequence or Level Sequence. It is well suited to turning existing voice or performance material into editable animation. Its official workflow still centers on input footage, solve settings, and asset export: a director must first prepare a performance, then refine it in the editor. The opening is to put dialogue relationships and on-set direction before generation. At a specific beat, a director could request an averted gaze, a delayed outburst, or a changed pause. The system would rerun only the affected section and retain comparable performance branches. The focus is not higher-fidelity facial capture, but letting teams without actor footage rehearse the scene first. - iClone 8: iClone 8 already offers mature facial controls and timeline editing. Users can adjust expressions at any frame and view tracks for muscles, blinks, eyes, head movement, and morphs. Tools like this suit animators refining work track by track and making precise keyframe edits. But directorial intent must still be translated into sliders, curves, and keyframes first. A writer or director cannot simply give an on-the-spot instruction and see a new performance from that beat onward. Nor does it naturally organize several local reruns into reviewable branches. The opportunity is a rehearsal-semantic layer above the timeline: natural-language direction becomes constraints on gaze, pauses, and poses before animators take over the curves. This would not replace iClone; it could instead pass a selected rough performance to iClone for further polish. ## How it makes money (model inference) Charge by team workspace subscription, with a fixed allowance for scene generation and version storage. Bill overages by rerendered duration, while keeping export tracks ungated so teams can take the results back into their existing production workflows. ## Source context Theme: Wizstar’s professional-actor-style digital avatars Trigger Product Hunt launch: Wizstar — Digital avatars that move and act like professional actors This records only that the launch appeared in Product Hunt's public feed and when it was observed. The feed provides no vote count; do not describe feed order as popularity or market demand. ## Sources - Wizstar (https://www.producthunt.com/products/wizstar) - Audio Driven Animation | MetaHuman Documentation (https://dev.epicgames.com/documentation/metahuman/audio-driven-animation) - opentimelineio.schema.Marker (https://opentimelineio.readthedocs.io/en/latest/api/python/opentimelineio.schema.html) - Using HD Face Control Panel and Timeline Display (https://manual.reallusion.com/iclone-8/Content/ENU/8.6/50-Animation/Pro_Facial_Animation/Using-HD-Face-Control-Panel-and-Timeline-Display.htm) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.