How 1,029 Storyboards Come From a 93,000-Character Novel

A 93,000-character novel split into 1,029 storyboards uses a two-level decomposition method. Level one: split the novel by chapters—93,000 characters into 69 chapters—and store them in the dbvideo_article table. Level two: use the funx.atctoscene function to run each chapter one by one. Each chapter automatically extracts characters and locations into the dbvideo_roles and dbvideo_places tables. When characters and locations collide, storyboards are generated automatically. The entire process requires no manual counting of shots and no hand-written storyboard sheets—you only need to enter the chapters correctly; the function handles the rest. What does level one split? It splits chapters. This doesn't mean copying and pasting paragraph by paragraph; it means splitting the entire novel into 69 independent records by chapter. Each record is one chapter, storing the chapter number and the body text in its fields. Why must it be split by chapter? Because every subsequent process operates at the chapter level. If you stuff the entire novel into one table at once, the system cannot determine where chapter boundaries are, let alone generate characters and locations independently for each chapter. Based on the experience of "The First Avenue," 93,000 characters split into 69 chapters averages about 1,300 characters per chapter—exactly the volume that the atctoscene function can handle stably. If you process content that's too long in one pass, characters get missed; too short, and you waste API calls. So the core action of level one is: split by chapter, one record per chapter, and store it correctly. How do you do it specifically? Once you have the original novel text, first manually scan the chapter list to confirm the total number of chapters. Then open the dbvideo_article table in the database and insert one record per chapter. Each record must carry the correct bookcode—the root node generated in dbvideo_bookidx during the "name first" step. Without this root, characters and locations can't attach to anything downstream. Based on experience, entering all 69 chapters takes about half a day if you're copying and pasting. Someone might ask: can I write a script to split chapters automatically? Yes, but only if the original work uses a consistent chapter format—for example, each chapter starts with a marker like "Chapter X." If the format is inconsistent, the script is prone to cutting in the wrong places. My recommendation is to do a manual pass for maximum reliability. The material explicitly states: name first, body second, then storyboards. This "body" refers to entering the full text chapter by chapter—it must not be sloppy. What does level two run on? The funx.atctoscene function, running one chapter at a time. When it runs, the function reads that chapter's body text and automatically extracts the people and locations that appear. Extracted characters go into the dbvideo_roles table; locations go into the dbvideo_places table. Here's a key point: the places table is not a location dictionary—it's one row per shot. That means it doesn't store a globally unique "palace" location; it stores entries like "Chapter 1 Palace" and "Chapter 2 Palace" as shot-level records. On the surface this looks redundant, but it actually guarantees that each shot's scene is independent and replaceable. The material specifically warned about this trap: many people assume the location table should be deduplicated, so they merge the same location across different chapters, and later when generating videos, scenes get crossed over everywhere. So the result of level two is 69 independent character lists and location lists. You can think of them as 69 small boxes, each holding that chapter's people and places. How are storyboards generated? It's just a collision between characters and locations. The formula is: scene = character + location; dbvideo_process = dbvideo_roles + dbvideo_places. One character in one location produces one storyboard record. For example, if a chapter has four characters and three locations, the cross-product could yield multiple storyboards—but it's not random pairing. The function automatically selects the reasonable combinations according to the narrative. Based on actual measurements from "The First Avenue," running all 69 chapters ultimately yields 1,029 storyboard records. This number isn't set by hand; it's determined by the total combination of characters and locations. In other words, if you switch to a different novel, even with a similar writing style, the storyboard count will differ because the character and scene counts differ. Don't expect to copy someone else's 1,029—whatever your own novel splits into, that's the number. Why 1,029 and not some other number? Because that's the natural result of combination. The material doesn't provide the specific character and location distribution for each chapter, but based on experience, this magnitude indicates an average of 15 to 20 storyboards per chapter. 69 chapters times an average of 16 shots equals about 1,100 shots. The actual number is 1,029, which means some chapters have fewer scenes and some have more—the distribution isn't uniform. This is precisely proof that it was automatically split, not manually divided evenly. If you hand-wrote storyboards, you'd likely make every chapter the same length, looking very neat but actually violating the story's rhythm. The beauty of automatic decomposition is that it stays faithful to the original text's character and location distribution—long where it should be long, short where it should be short. 1,029 is simply what it naturally is. Where does this process most easily break down? Based on experience, it's that step one isn't done thoroughly. Someone can't wait to run atctoscene, only to find that the bookcode wasn't entered or was entered incorrectly, and the function returns completely empty tables. Another person enters chapters into the article table with the chapter numbers in the wrong order—entering chapter one twice and skipping chapter five—resulting in a storyboard table missing that chapter's content, and the generated video later has a large gap in the story. The material specifically states that atctoscene has an idempotency lock and cannot be re-run, meaning that once you've run a chapter, if you discover an error and want to re-run it, the system will block you. So the worst-case scenario is entering data carelessly, causing an error on the first pass, with no chance to correct it. Based on experience, after entering the article table, count once to confirm it's 69 chapters before starting the run. Are there counterexamples? Yes. Someone thought more storyboards is better and, to inflate the shot count, forcibly broke one scene into multiple scenes and added a few fabricated characters. The result: the character table gained a bunch of names that don't exist in the original work, locations grew out of thin air, and the storyboard count ballooned—but the generated visuals didn't match the story at all. The material emphasizes that the essence of this design is turning a film into enumerable, re-runnable, replaceable records—not padding volume. Storyboard count should faithfully reflect the original text's character and location combinations. If you artificially add things, you're polluting the data, and every downstream step pays for that mistake. The reverse counterexample also exists: someone, to reduce workload, merged multiple locations into one—calling the palace, main hall, and side hall all "palace." The result: a scene of characters talking in the main hall generated a full palace wide shot, and the scene was completely wrong. So don't tamper with the data—let the function split naturally, and whatever number it produces is the number. What do you have after these two steps? You have the dbvideo_process table containing 1,029 storyboard records, each corresponding to one character and one location, plus the prompt template identifiers needed downstream. Subsequent image generation follows three paths: characters through drawrole via Volcano Engine synchronous direct call, locations through placeaiwords' empty-rolex branch, and scenes through placeaiwords' character-present branch plus scenetopic compositing. Each shot produces two images—first frame -a and last frame -b—and the first and last frames drive image-to-video generation. In other words, these 1,029 storyboard records are the skeleton of the entire film. All subsequent visuals, sound, and editing pull data from this table for generation. The cleaner you make this table early, the lower your downstream costs and the less rework. What's the immediate next action? Take a short story you have on hand—no need for 93,000 characters; just one or two thousand characters is fine—split it by chapter, enter it into the dbvideo_article table, set the correct bookcode, then call funx.atctoscene to run one chapter. After the run, check how many character records and location records were generated in the dbvideo_roles and dbvideo_places tables, then check how many storyboards dbvideo_process automatically produced. Based on experience, a one-thousand-character chapter can yield ten to fifteen storyboards. First, get this small-scale experiment working and feel out the principle of automatic decomposition, then decide whether to scale up to the 93,000-character level. Remember: the essence of this workflow isn't teaching you how to write storyboards—it's letting you never have to write them.