Two-Level Decomposition: 93,000 Characters to 1,029 Shots

A 93,000-character source novel must undergo two levels of decomposition to become a film: the first level splits the novel into chapters, and the second level splits chapters into shots. The first-level decomposition looks simple—just dividing the full text by logical paragraphs—but in practice it is not a matter of someone reading through and manually drawing lines; it depends on the book's structure. In the CloudKude system, a book title is first entered into the `dbvideo_bookidx` table, generating a `bookcode` as the root node of the entire universe. This root node contains no body text; it only identifies the existence of the book. Next, the second table, `dbvideo_article`, is populated with the full text entry by entry, each entry corresponding to a chapter. Each record includes the chapter title, body text, and an `atctype` field that determines the art style. The entry is not typed out manually in a document; rather, existing electronic text is split by chapter and imported directly, one `articlecode` per entry, as a child node of the `bookcode`.

The 93,000 characters ultimately distribute across sixty-nine chapters, averaging roughly 1,348 characters per chapter. But this average masks significant length variation between chapters—the shortest chapter is only 600 characters, while the longest exceeds 2,500. The second-level decomposition is the core of the entire process, executed automatically by the `funx.atctoscene` function. This function reads a single chapter from `dbvideo_article`, scans the body text, extracts characters and names, as well as locations and places, and then, based on action and state changes in the sentences, splits the chapter into multiple shots. Each shot is an independent minimal narrative unit containing an executable visual prompt. The output of `atctoscene` is automatically written into three tables: `dbvideo_roles` records all characters appearing in that chapter, `dbvideo_places` records all locations, and `dbvideo_process` records the storyboards themselves. Each row in the storyboard table represents one shot, with foreign keys linking to the character ID and location ID that appear in that shot. This confirms the formula that a scene equals a character plus a location: `dbvideo_process` is in essence the join product of `dbvideo_roles` and `dbvideo_places`.

But `atctoscene` does not run through the entire book at once; it runs chapter by chapter, executing once per entered chapter. The benefit of this approach is that it allows mid-course checking—if the decomposition quality of one chapter is poor, that chapter's text can be corrected and re-run individually without affecting other completed chapters. Take a specific chapter as an example. Suppose the chapter is titled "The Five Elements Dragon Flag First Appears," with a body of roughly 1,500 characters, describing the protagonist Lin Xuan encountering a mysterious old man on Mount Cangwu and discovering the dragon flag. The `atctoscene` output for this chapter is fifteen shots. The first shot: character Lin Xuan, location Cangwu Mountain Foot, action described as Lin Xuan looking up at the distant peaks. The second shot: character Lin Xuan, location Mountain Path, action as Lin Xuan walking upward along the stone steps. The third shot: no character, location Cangwu Mountainside, action as a mist-shrouded distant view. The fourth shot: character Old Man, location Stone Platform on the Mountainside, action as the old man sitting cross-legged with eyes closed. The fifth shot: characters Lin Xuan and Old Man, location Stone Platform, action described as Lin Xuan approaching and cupping his fist in greeting. The sixth shot: character Old Man, location Stone Platform, action as the old man opening his eyes and gesturing for Lin Xuan to sit. The seventh shot: characters Lin Xuan and Old Man, location Stone Platform, action as the old man tells the dragon flag legend while Lin Xuan listens intently. The eighth shot: no character, location Stone Platform, action as a gust of wind stirs the old man's robe. The ninth shot: character Old Man, location Stone Platform, action as the old man takes a worn flag from his sleeve. The tenth shot: characters Lin Xuan and the Flag, location Stone Platform, action as Lin Xuan takes the flag and examines it. The eleventh shot: character Lin Xuan, location Stone Platform, action as Lin Xuan asks the old man about the flag's origin. The twelfth shot: character Old Man, location Stone Platform, action as the old man shakes his head, saying the time is not yet right. The thirteenth shot: characters Lin Xuan and Old Man, location Stone Platform, action as the old man rises and walks toward the cliff edge. The fourteenth shot: no character, location Cliff Edge, action as the old man's figure gradually merges with the mist. The fifteenth shot: character Lin Xuan, location Stone Platform, action as Lin Xuan grips the dragon flag tightly, gazing ahead with determination.

Across these fifteen shots, the character and location tables do not add a new record for every shot. Once character Lin Xuan appears in the first shot, `dbvideo_roles` establishes the character ID for Lin Xuan, and subsequent shots reuse that ID without duplicate creation. The locations Cangwu Mountain Foot, Mountain Path, Cangwu Mountainside, Stone Platform, and Cliff Edge each get their own location records, with the Stone Platform recurring across multiple shots. The deduplication logic in `atctoscene` is clear: characters and locations are unique by name, but every row in the storyboard table is a brand-new record. Even for the same character and same location, a different action produces a new storyboard ID. Thus, the 1,029 shots do not correspond to 1,029 distinct scenes, but rather to a series of action sequences across various character-location combinations in different states. The boundary between shots is determined by continuity of action and state; a continuous descriptive passage can be split into two shots whenever there is a clear spatial or temporal transition between the actions before and after. For instance, the third shot is a pure landscape display with no character and no location—it is an empty shot, but still a shot, enriching the visual rhythm.

One also needs to understand why the chapter count is far smaller than the shot count. Sixty-nine chapters are the product of first-level decomposition, while 1,029 shots are the result of second-level decomposition. On average, each chapter yields fifteen shots, but in reality some chapters produce as few as six shots and others as many as twenty-three. The difference comes from text density. A dialogue-heavy chapter may produce only seven or eight shots, because characters' positions in dialogue scenes are relatively fixed with fewer action transitions. A chapter containing transitions, chases, or battles will produce a large number of shots. The `atctoscene` design must handle this non-uniform splitting; it cannot cut evenly by character count but must recognize semantic boundaries. For example, transition phrases in the text such as "as the sun set in the west, the scene shifted indoors" are natural storyboard cut points. When entering text into `dbvideo_article`, no manual annotation of storyboard points is required; the full text is entered as-is, and `atctoscene` automatically identifies location shifts, time changes, and character entrances and exits within sentences. This also means the manual workload is concentrated mainly in the early entry stage—the clearer and more complete the entry, the more accurate the number of automatically decomposed shots.

One issue to be careful about during the storyboard process is that `atctoscene` carries an idempotency lock. Once a chapter has run successfully, it cannot be run again, even if the text is corrected and resubmitted—the request will be rejected. This guarantees the stability of storyboard data, but it also requires the entry stage to ensure quality as much as possible, avoiding situations where repeated text revisions make it impossible to regenerate storyboards. If a re-run is truly necessary, the chapter's lock record must be manually released, which is cumbersome and can easily break the existing associations between storyboards and other tables. In practical terms, the recommendation is to run `atctoscene` once immediately after entering each chapter, check whether the output is reasonable, and if problems are found, correct them quickly before that chapter is locked. Since the book has sixty-nine chapters, entry and storyboard generation are interleaved: enter one chapter, run it once, then review whether the counts in the character table, location table, and storyboard table are reasonable. When all sixty-nine chapters have been processed, all 1,029 shots are stored. At that point, how many unique characters exist in the character table, how many unique locations exist in the location table, and how many shots exist in the storyboard table are all fixed. All subsequent image generation and video synthesis are based on these three relational tables and no longer return to the source text. The novel is merely the raw material for generating shots, while the storyboard table is the true data platform driving film production.