From 93,000 Characters to 1,029 Shots: The Automated Decomposition Principle
dbvideo_bookidx` is the root starting point for all film creations in the Yuncao Academy system.
The table's field design is extremely streamlined. Core required fields include `bookcode`, `bookname`, `author`, and `createtime`. Among these, `bookcode` is a globally unique string code, similar to an ISBN, but it is auto-generated internally.
When a book is entered, the operator fills in the title and author in the management interface, and the system automatically assigns a `bookcode`, such as BKD20240001.
From then on, all data related to that book—including the full text, characters, locations, and storyboards—is linked through this `bookcode`.
The `dbvideo_article` table is the storage repository for the main text. Its key fields are `artcode`, `bookcode`, `arttitle`, `artcontent`, `atctype`, and `artorder`.
`artcode` is the unique code for each chapter, `bookcode` points to the book it belongs to, `arttitle` is the chapter title, `artcontent` stores the complete chapter text, `atctype` is the art style identifier—where `xs` means realism, `gz` means costume drama, `dm` means anime, and `xd` means modern—and `artorder` determines the sequence of the chapter in the film.
Data entry typically uses batch pasting. The operator copies chapter content from a txt file segment by segment into the entry interface, and the system auto-splits it by paragraph, writing each natural paragraph as a record into `dbvideo_article`.
During entry, note that the `atctype` field must be manually selected based on the chapter content, because subsequent storyboard splitting and image generation will directly inherit this value.
The `funx.atctoscene` function is the core engine for converting text into storyboards.
Its input parameter is `artcode`, and its output result set consists of three write actions: writing character records to `dbvideo_roles`, writing location records to `dbvideo_places`, and writing storyboard records to `dbvideo_process`.
The internal execution logic is divided into four stages.
Stage one is text cleaning: removing punctuation interference, normalizing the capitalization forms of person and place names, and marking dialogue within quotes as spoken lines.
Stage two is named entity recognition. The system has a built-in domain dictionary that preloads common Chinese person-name surnames and place-name suffixes, such as city, town, mountain, river, hall, and mansion.
BODY:
The recognition strategy includes two approaches. One is top-down scanning of each sentence: when a noun is preceded by a subject action verb and that noun does not already exist in the character table, it is treated as a potential character and added to a temporary list.
The other is spatial relationship matching: when locative words such as southeast, northeast corner, or beside appear in a sentence, the noun that follows is more likely to be recognized as a location.
Stage three is storyboard splitting. Based on natural sentence breaks in paragraphs and action continuity, a segment of text is divided into multiple shot units, each corresponding to one record in `dbvideo_process`.
The splitting is driven by verb changes and scene transitions. For example, if a paragraph contains a description of moving from the city gate to inside the main hall, the system automatically identifies two visual segments: the first takes the city gate as its location, the second takes the main hall, and each generates an independent shot number.
Stage four is relation linking. The recognized character records and location records are associated with the current storyboard record through foreign keys. The `dbvideo_process` table contains fields such as `scenecode`, `bookcode`, `artcode`, `scenename`, `rolex`, `placex`, `aiwords`, and `imgstyle`.
`rolex` and `placex` are foreign key references to character codes and location codes. A single storyboard can reference one character and one location, or it can reference only one character or only one location.
Take a chapter from the original text as an example. The chapter is titled "Lin Xuan Enters the Five Elements City for the First Time," with a total of approximately 1,300 characters.
After splitting, twelve storyboard records were generated.
The first storyboard corresponds to the scene where Lin Xuan steps down from the carriage in the original text. `rolex` is filled with a character reference from the character table, `placex` is filled with the location reference for the Five Elements City gate, and `scenename` is auto-generated as "Lin Xuan steps down at the Five Elements City gate."
The second storyboard corresponds to Lin Xuan walking through the market. `rolex` remains unchanged, and `placex` becomes the Five Elements City market.
The third storyboard corresponds to Lin Xuan entering the tavern. `rolex` remains unchanged, and `placex` becomes the tavern interior.
The fourth storyboard is the dialogue scene with the tavern owner. `rolex` changes to a different character—the owner—while `placex` remains the tavern interior.
Among these twelve storyboards, two shots contain only a location without a character. For example, one empty shot depicts a flag fluttering atop the city wall. The system automatically leaves `rolex` empty and assigns `placex` to the city wall.
The entire splitting process requires no manual input of prompts for any shot. All field values are auto-generated and then written.
The idempotent lock mechanism is the most important safety design in `funx.atctoscene`.
BODY:
At the very start of the function, the system executes a query to check whether any record already exists in the `dbvideo_process` table where `artcode` equals the input value.
If any record exists, the function immediately returns a message indicating that the chapter has already been split, and no append operation is performed.
The purpose of this lock is to prevent data duplication and context corruption.
Without this lock, if an operator accidentally ran the split twice on the same chapter, `dbvideo_roles` would contain duplicate character records, `dbvideo_places` would have entries for the same location but with different codes, and the shot numbers in `dbvideo_process` would all be misaligned. Subsequent image generation and video generation tasks would then reference incorrect storyboard records.
Another risk of re-running is that if a chapter has already produced several hundred first and last frame images, re-running the split function would generate a new batch of storyboard codes, leaving all the old images as orphaned files that could no longer be linked to the new storyboard records.
Therefore, the correct re-run procedure is to first delete all records from the four tables associated with that chapter—`dbvideo_process`, `dbvideo_roles`, `dbvideo_places`, and `dbvideo_arcpictask`—and only then re-invoke the function.
The advantage of automated splitting over manual shot breakdown is overwhelming. First, there is consistency. When a human splits a thousand shots manually, they might produce two hundred different description styles, whereas automated splitting generates storyboard records that all follow the same naming conventions and behavioral logic, allowing subsequent prompt templates to be applied uniformly.
Second, there is traceability. Every auto-generated storyboard record carries an `artcode` pointing back to the original text. If the visual result of a shot is unsatisfactory, you can always trace back to the original paragraph and make modifications.
Third, there is speed. A human editor splitting one shot per minute is already at the limit—1,029 shots would require eighteen hours of uninterrupted work. In contrast, `atctoscene` processes one chapter in an average of just thirty seconds.
The entire 69-chapter split is completed in roughly forty-five minutes.
Automated splitting still has edge cases that require manual correction. The four most common situations are as follows.
The first is the character alias problem. For example, a character in the original text may use different titles across chapters—referred to as Lin Xuan in earlier sections and Young Master Xuan in later ones. The system may recognize these as two separate characters.
The correction method is to finish splitting that chapter first, then merge the two character entries in `dbvideo_roles`, pointing the latter's `rolex` to the earlier code.
BODY:
The second is location ambiguity. For example, the original text may repeatedly mention "the city gate," but these references could point to different gates—the south gate and the north gate have vastly different visual representations.
In this case, multiple records need to be created in `dbvideo_places` for different scenes under the same name, with directional descriptions added to each.
The third is empty-shot recognition.
The system tends to split every sentence containing action into a storyboard with a character, but many atmospheric passages have no character present at all, such as a mountain sea of clouds under an approaching storm.
Manual intervention is required to separate these passages from character-bearing shots and generate an independent storyboard with `rolex` left empty.
The fourth is dialogue-heavy scenes where multiple speakers share a single shot. The system may generate several storyboards, resulting in overly frequent cuts. These need to be manually merged into a single shot, with the system retaining the first frame from the first storyboard and the last frame from the final storyboard.
These corrections are all made by directly editing records in the database management interface. Once the edits are complete, re-running the image generation task will not affect the data integrity of other shots.