Tshivhidzo Mbedzi AI & Technology Specialist

Projects Hoshi Nova

Operational AI Product Development September 2026 – present

Hoshi Nova

AI-assisted animation production platform

A desktop application that turns a written episode into a finished 4K animated video: script, cast, voices, lip-sync, camera, render, score, mix and credits.

My role
Sole builder, director and operator
Period
September 2026 – present
Category
AI Product Development
  • 20 Episodes produced Two 10-episode seasons
  • 3840×2160 Output resolution Verified per master with ffprobe
  • 11:02 Longest episode verified The Long Way Up, episode 1
  • ≈1.5–4 h Render time per episode Depends on temporal sampling

In short

  • Produced 20 episodes at verified 3840x2160, unattended, from structured data.
  • An automated gate measures every delivered file and restores the previous version rather than shipping a failure.
  • Found systemic animation defects by automated geometry scanning, after they had already passed human review.

Project overview

Hoshi Nova is a standalone Windows application that produces finished animated episodes with as little manual intervention as possible. An episode is defined as structured data — scenes, characters, dialogue, camera marks, moods. The application resolves that into a cast with synthesised voices, drives a 3D engine to render the frames, assembles and mixes the audio, applies a score and credits, and writes a single delivered master file.

The design constraint that shaped everything is that it must run unattended. I direct an episode, start a queue, and the machine finishes it without an AI assistant in the loop — because a ten-episode season is roughly a day and a half of continuous rendering and nothing that needs supervision at 03:00 is a production tool.

The problem being addressed

Independent animation is gated by labour, not by ideas. A ten-minute animated episode conventionally needs a writer, a voice cast, an animator, a compositor, a sound designer and an editor. For one person that is not a scheduling problem, it is an impossibility.

The second problem is quality drift. Generative tools make it trivially easy to produce something that is technically a video and obviously worthless — wrong resolution, flat vocal delivery, limbs passing through torsos, a soundtrack that is really a sine wave. Automating production without automating quality control just produces failure faster.

The solution

A pipeline where every stage is a separate, inspectable program with a defined input and output, plus an automated gate before delivery.

Episodes are data, not timelines, so they can be regenerated, diffed and re-rendered. Voice synthesis is pluggable, so a character's voice is a configuration value rather than a recording session. The 3D stage is driven by script through the engine's own Python API, which means set construction and camera work are reproducible. And nothing is delivered until it has been measured: resolution, frame rate, audio levels, and narration checked back against the written script by speech recognition.

How it works

An episode goes in as text. A finished 4K film comes out the other end, with voices, lip-sync, camera work, a score and credits — and nobody touches it in between. Here is what happens in those few hours.

  1. The episode is data, not a timeline

    A video editor stores an episode as a timeline: a fixed arrangement of clips you edit by hand. This stores it as structured data — scenes, who speaks, what they say, where the camera sits, the mood of each beat. That single choice is what makes everything after it possible, because data can be regenerated, compared against a previous version and re-rendered. A timeline can only be edited.

  2. Casting resolves to actual voices

    Each character maps to a synthetic voice, and that mapping is configuration rather than a recording session. Changing who plays a part is a one-line change, not a day in a studio. Every line in the script is synthesised, and each character keeps the same voice for the whole episode.

  3. The set is built by script

    The 3D environment is constructed by code talking to the engine through its own Python interface — walls, props, lighting, camera positions. Because it is scripted, the same set rebuilds identically every time, and a change to the set is a change to a file rather than an afternoon of dragging objects around.

  4. Performance is assembled from clips and shapes

    Dialogue drives facial shapes for lip-sync. Body movement comes from a library of acting clips. The camera moves to marks defined in the episode data. This is the stage where a scene stops being a description and becomes something you can watch.

  5. Render, then assemble

    Frames are rendered at 3840x2160 and written to disk, then assembled with the synthesised dialogue, the score and the effects into a single file. This is the slow part — hours, not minutes — which is exactly why no human waits for it.

  6. The gate decides whether it ships

    Before anything is called finished it is measured: resolution, frame rate, programme loudness, and the narration transcribed back by speech recognition and compared to the script. Pass, and it is delivered. Fail, and the previous version stays and the new one does not go out.

Technology stack

Application

  • Electron
  • Node.js
  • JavaScript

Rendering

  • Unreal Engine 5.8
  • Blender
  • Unreal Python API

Speech & audio

  • Kokoro TTS
  • Chatterbox TTS
  • Whisper ASR
  • ffmpeg / ffprobe

Assets

  • VRM / glTF characters
  • Mixamo skeletons
  • Meshy-generated models

Orchestration

  • Python queue scripts
  • Resumable job logs

System architecture

Hoshi Nova production pipeline An episode defined as structured data passes through cast resolution, voice synthesis, scripted set construction, 3D rendering, assembly and mixing, and an automated delivery gate that rolls back to the previous master on failure. Episode as structured data scenes · dialogue · camera marks · moods Cast & voice resolution Scripted set construction Unreal Python API Speech synthesis per-character voices Animation & camera lip-sync · acting clips Frame render Unreal Engine / Blender · 3840×2160 Assembly & mix ffmpeg Score & credits Stages are separately runnable, so a mix fault does not cost a four-hour render. Delivery gate resolution · frame rate · loudness · ASR vs script · collision scan A failed gate restores the previous master rather than shipping the new one. Delivered 4K master Previous master retained
Hoshi Nova production pipeline — An episode defined as structured data passes through cast resolution, voice synthesis, scripted set construction, 3D rendering, assembly and mixing, and an automated delivery gate that rolls back to the previous master on failure.

My responsibilities

  • Defined the episode data format and the stage boundaries of the pipeline.
  • Built and maintained the Electron application, the render orchestrator and the CLI.
  • Directed all twenty episodes: story structure, casting, dialogue, camera and pacing.
  • Wrote the automated quality gate and the verification scripts that approve a master.
  • Managed render scheduling, GPU contention and the storage lifecycle of intermediates.
  • Diagnosed and fixed pipeline defects found in delivered output, including animation faults.

Development process

  1. Smallest working version first

    One episode, rendered badly, end to end — before any attempt at a season. The first delivered pass was accidentally 1080p, which is exactly the kind of error an end-to-end run surfaces and a component test does not.

  2. Make every stage separately runnable

    Voice, render, mix, credits and finalise are individually invokable. A failure in the mix does not cost four hours of rendering, and a fix can be verified on one stage in seconds.

  3. Then automate the queue

    A resumable queue with a per-episode log. It survives the session that started it, so a crash or a closed terminal does not lose a night of rendering.

  4. Gate before delivery

    Each master is probed for resolution, frame rate and audio level, contact-sheeted for visual review, and narration-checked against the script. A failed gate restores the previous master rather than shipping the new one.

Challenges encountered

Intermediates filled the disk

4K frame sequences are enormous. Rendering a single episode to PNG costs roughly 221 GB, and frames for ten delivered episodes were never cleared — about 620 GB of output for work that had already shipped, leaving the drive with under 5 GB free and blocking all further rendering. Two changes came out of it: frames are written as JPEG from 1440p upward, and intermediate cleanup is now part of the delivery step rather than an afterthought. The lesson generalised: in a media pipeline, storage lifecycle is a feature, not housekeeping.

Animation that looked fine in review and was broken on inspection

A collision scan of the clip library found that 61 of 70 animation clips had limbs intersecting the character body, by as much as 16 cm. None of it was obvious at playback speed. I wrote a Blender correction pass and a scanner that measures the closest approach between characters across an entire episode — the measured minimum separation came out at 0.92 m, which also proved that scripted beats involving physical contact had no contact animation at all and had to be staged as cutaways instead.

The score was not music

The first ten episodes shipped with what the pipeline called a score and was in fact mathematically generated sound effects sitting about 29 dB down — effectively inaudible and not music by any definition. The owner-facing lesson was mine to learn: the pipeline reported success because a file existed at the expected path. Existence is not a quality check. The hosted music API I reached for next returned a payment-required error on a free plan, so the fallback is a built-in composer, with licensed tracks mixed roughly 8 dB under dialogue.

A quality gate that measured against the wrong geometry

The pre-render checker validates that characters and cameras sit inside the set. It was written against one production's wall geometry and, run against a different production, "corrected" scenes to the wrong walls — a destructive automated fix. It is now explicitly scoped to the production it was built for, and that constraint is documented at the call site. An automated fixer needs a narrower contract than an automated checker.

Testing and validation

Container and signal verification

Every delivered master is probed: 3840×2160, 24 fps, AAC stereo, programme level near −18 dB. A master that misses any of these is not delivered.

Narration against script

Speech recognition transcribes the rendered narration and the result is compared to the written line, which catches synthesis dropouts and wrong-take errors that no one hears on a first listen.

Geometry and collision scanning

Automated scans for character self-intersection and inter-character overlap across every scene of every episode, rather than spot checks.

Visual contact sheets

A frame grid per episode for human review — the cheapest way to catch a lighting or camera fault across eleven minutes.

Evidence and demonstrations

This project is publicly inspectable. The links below are the demonstration — a live page you can open is stronger evidence than a screenshot I could have made in any image editor.

Source code is not currently published. Publishing this portfolio repository and making my work reviewable is step 2 on my roadmap, and it is a hiring problem before it is a technical one. I am happy to walk through any of this code in a screen share.

Current development status

Built, tested and in use

  • End-to-end production of a 4K episode from structured data, unattended.
  • Twenty episodes delivered and published across two seasons.
  • Voice synthesis with per-character assignment and lip-sync.
  • Scripted set construction and camera work through the engine Python API.
  • Automated delivery gate with rollback on failure.
  • Resumable render queue independent of the controlling session.

Not built, or not proven

  • Local music generation — the model install never completed on the available connection; the built-in composer is the current path.
  • A systematic voice-emotion audit. Delivery mood versus line intent is still judged by ear.
  • The redesigned set. It conflicts with existing standing staging and needs supervised import.
  • Any multi-user or cloud rendering capability. This is a single-workstation tool.

Future improvements

  • Replace by-ear voice direction with a measurable prosody check against the intended mood per line.
  • Treat intermediates as a managed cache with a size budget, rather than relying on a cleanup step.
  • Extend the delivery gate to cover subtitle timing and loudness normalisation to a broadcast standard.
  • Distribute rendering across a second machine — the groundwork exists but the node is switched off.