Name, Body, Then Storyboard: Three Sentences That Wire the Entire AI Filmmaking Pipeline
First the name, then the body, then the storyboard.
These three sentences are not a mantra but the physical order of the entire AI filmmaking pipeline.
The first sentence lands in the dbvideo_bookidx table, recording the book title and metadata, and generating a unique bookcode field. This field acts like the root node of a global namespace, and all subsequent data hangs on this tree.
The second sentence lands in the dbvideo_article table, entering the full original text article by article. Each record contains articlecode, chaptertitle, content, and atctype, where atctype determines the visual style of the entire work—for example, xs stands for realistic, gz for period costume, and dm for animation.
The third sentence lands in the call to funx.atctoscene, which automatically scans every entry in dbvideo_article, extracts character names and location names from them, and writes them into dbvideo_roles and dbvideo_places respectively. At the same time, it cross-references these two sets and generates a storyboard record for every sentence that contains both a character and a location, writing the result into dbvideo_process.
The entire flow moves from root to branch to leaf, and each step's output is the next step's input—there is no skipping of levels.
To observe the data flow with an arrow diagram: dbvideo_bookidx (bookcode) points to dbvideo_article (articlecode); dbvideo_article (content) points to funx.atctoscene; atctoscene outputs in two directions simultaneously—left to dbvideo_roles (rolecode) and right to dbvideo_places (placecode); and dbvideo_roles and dbvideo_places together point to dbvideo_process (scenecode).
The core of this diagram is not each table itself, but the edges between them.
bookcode is the root, but it does not participate in any shot computation; it only serves as an ownership tag.
articlecode is the body, carrying the text input.
rolecode and placecode are the decomposed atomic elements.
scenecode is the synthesized result.
Every operation on each edge has a clear function: from article to roles, atctoscene performs named entity recognition; from article to places, the same atctoscene performs location extraction.
BODY:
From roles and places to process, the rule is scene composition: when a character and a location appear in the same sentence, a shot is generated.
Here, the roles table is not a character dictionary but a set of character instances appearing in each article; the places table is likewise not a location dictionary but stores one row per shot. This design ensures that process generation can directly reference them without extra deduplication logic.
Why must characters and locations be separated into their own tables first, rather than generating storyboards directly?
This question concerns the correctness of the composition logic.
A scene equals a character plus a location. If characters and locations were mixed together—for example, storing a combined list of all people and places in one table—then generating a storyboard would require an extra part-of-speech check, increasing the chance of error.
By keeping them in two separate tables, atctoscene can treat character recognition and location recognition as two independent pipelines, each using different model weights.
Character recognition relies more on name databases and contextual pronouns; location recognition relies more on geographical nouns and spatial prepositions.
At the code level, the character extraction function outputs rolecode, rolename, and appearance fields, while the location extraction function outputs placecode, placename, and environment fields—the two never interfere with each other.
When processing a given passage, if the character pipeline hits Lin Xuan and the location pipeline hits Cangwu Mountain, and both hits occur simultaneously, the system considers that sentence to constitute a scene.
If only a character is hit but no location, or only a location is hit but no character, then no process record is generated.
This explains why the 1,029 shots do not correspond to every sentence having a complete person and place—some empty shots are dedicated solely to establishing the environment.
This design makes the generation process replayable.
When atctoscene processes article X in dbvideo_article, it first splits the full text into sentences and evaluates each one.
For the second sentence in article X, "Lin Xuan walked upward along the stone steps," the character pipeline identifies Lin Xuan, and the location pipeline infers from context that the current position is the foot of Cangwu Mountain. Both outputs fall within the current sentence's time span, so the sentence is flagged as a candidate shot.
Next, atctoscene assigns a scenecode to this shot and writes it into the process table.
The shot's content does not come directly from the original sentence; instead, a subsequent prompt template generates the visual description based on the character and location.
BODY:
Then the inflection point appears: the storyboard table does not need to store the original sentence text—it only carries rolecode, placecode, and a blank aiwords field, which is reserved for the video prompt to be filled in later.
This design makes a storyboard a pure associative structure. Its entire purpose is to connect two independent elements—character and location—and each element can be replaced independently. To change an actor, you only update the record in roles; to change a scene, you only update places; the references in process follow automatically, without rerunning the entire storyboard pipeline.
The order of "one gives birth to two, two gives birth to three, three gives birth to all things" corresponds exactly to this data cascade.
One is the book title, i.e., bookcode—a single root.
Two is the main text, i.e., the sixty-nine articles—multiple entities produced by the one.
Three is the storyboard, i.e., the 1,029 scenes—the result of characters and locations colliding within the main text.
All things are the subsequent images, videos, and audio, all driven by the storyboard table.
If we map the whole chain back to Laozi's original logic: "The nameless is the beginning of heaven and earth" corresponds to bookidx, "the named is the mother of all things" corresponds to article, and "three gives birth to all things" corresponds to the part where process extends toward video.
In actual production, the moment the process table is generated, every subsequent row is converted into images by drawrole and placeaiwords; then the images drive video generation, and each video segment continues to expand into a complete film.
The output scale at each step is an order of magnitude larger than the previous one: one bookcode governs sixty-nine articles; sixty-nine articles produce 1,029 process records; each process record yields two keyframes (start and end); and ultimately this drives continuous visual content on the order of ten minutes.
This is why the entire system must strictly follow the order of name, then body, then storyboard—no skipping steps.
If you enter articles before bookidx is generated, you cannot determine which book a new chapter belongs to; an empty bookcode means every downstream stage lacks ownership, and in multi-company collaboration, data will get mixed up.
If you run atctoscene before all articles are fully entered, the character and place tables will be generated prematurely, but newly added chapters afterward cannot be associated with the existing character table, because the character table contains duplicate-name entries without a unique constraint.
BODY:
The idempotency lock in atctoscene further locks down this ordering constraint. It requires that each article be processed within its own lifecycle; once processed, even if the body text is modified, it cannot be rerun. This forces the recorder to stay disciplined: build the book first, then enter the body text passage by passage, and immediately call atctoscene after each passage to generate the intermediate artifact.
The sixty-nine chapters are not fully entered all at once before starting the storyboard pipeline. Instead, processing happens alongside entry, so each chapter's character and location tables can be instantly linked to existing chapters, laying the groundwork for multiple companies to share character resources within one world.
In the end, from the single root planted in dbvideo_bookidx to the 1,029 shots spread across dbvideo_process, the entire chain fully covers every conversion step from text to visuals. Each layer is connected through explicit field references, and each edge is driven by a runnable function.