The Most Commonly Missed Database Table in Solo AI Filmmaking

The most commonly missed table is dbvideo_places. Many people run atctoscene, see the characters populating dbvideo_roles, see the storyboard table generated, assume the job is done, and never notice that the places table is still empty. But it's not a table you can leave empty—it's the most counterintuitive table in the entire pipeline. The material lists this directly among the five pitfalls you will step in: places is not a location dictionary; it's one row per shot. Miss it, and every shot composite downstream collapses. How is the places table designed? One row per shot. What does that mean? It doesn't mean storing one record per location that appears in the novel, dictionary-style—like one entry for "palace," one for "city gate," one for "inn." Instead, every single shot stores its own location row. If thirty shots out of the total 1,029 take place at an inn, then the places table has thirty rows written "inn," each row corresponding to a specific storyboard. What it stores isn't a location lexicon—it's the binding relationship between shots and locations. The material states clearly: use funx.atctoscene to run through each chapter, which automatically extracts people and places into dbvideo_roles and dbvideo_places while also generating dbvideo_process. That is, one run of storyboard generation writes three tables synchronously: character table, location table, and storyboard table. The places table isn't maintained manually later—the program populates it automatically. But if you don't fully understand this mechanism, you might think you need to hand-fill a location checklist; you end up filling a bunch of duplicate location names, and when the storyboards actually run, the program can't find the corresponding shot binding relationships. What happens if it's missing? The formula "scene equals character plus location" fails outright. One of the two must-remember formulas in the material is: scene equals character plus location, and dbvideo_process equals dbvideo_roles plus dbvideo_places. If the places table is empty, or contains only a few dictionary-style location names, then when dbvideo_process generates, every storyboard can't find its own location binding—the scene ends up with only a character and no location. Downstream image generation gets worse: generating the character alone through drawrole works fine, but when the scene goes through placeaiwords' character-present branch, it needs the fmpic character image and the plcpic location image to composite. If plcpic has no data, the composite interface either errors out or produces a mangled image. Even worse: some beginners, finding the places table empty, add one "palace" entry as a global location. Then every shot composites with that single location, and all scenes become the same palace—crossover so bad you can't watch. This is exactly why the material stresses "not a location dictionary"—if you fill it with dictionary thinking, you'll use one location to overwrite all shots. Why is it counterintuitive? Because you think you're storing location names, but you're actually storing the binding relationship between shots and locations. The typical table-building approach: create a location table first, then a shot table, with the shot table's foreign key referencing the location table. But the Yuncao Academy system is different—its places table is generated backward from the storyboards. Each row is one specific shot's dedicated location description. In this shot, the protagonist fights on top of the city wall—that row stores the detailed visual description and scene prompt for "city wall." In the next shot, the protagonist jumps off the wall into an alley—then a new row stores "alley." The two rows have no relationship and don't borrow from each other. So if you build the table with traditional database thinking, making it a location dictionary, then all shots share one location record at runtime, and visually, all the different scenes become variations of the same place—the entire film loses its scene variety. How do you check, based on experience? After running atctoscene, count the rows in the places table, then compare against the storyboard row count in dbvideo_process. The material gives specific numbers: 1,029 shots, so the places table should have roughly 1,029 rows. If the row count is far below the storyboard count—say, only a few hundred—you built it wrong. The correct situation is that the two are roughly equal; a very few shots might be judged as pure empty scenes with no specific location and skipped, but the proportion won't be high. There's an even quicker check: directly look under that bookcode in the books table, and compare the row counts of dbvideo_roles and dbvideo_places—they should be on the same order of magnitude. If characters number in the hundreds and locations number in the teens, you've probably used places as a dictionary again. The material says that after storyboard generation, people and places are auto-extracted and three tables are generated simultaneously, so under normal results, the places table's row count should be very close to the process table's—not a small dictionary. What mistake do beginners most often make? Treating the places table as a manually maintained metadata table. Someone runs atctoscene, sees the places table has no data, and manually stuffs rows in. The rows are all duplicate chapter names like "Chapter One" and "Chapter Two," or even the novel title. These records can't be read by the downstream scene compositing flow, because compositing uses the plcpic location image linked to the storyboard. Those hand-stuffed records have neither generated a corresponding location image nor established a link to any storyboard—so it's like building nothing. Based on experience, a more subtle mistake: the places table exists, but the foreign key field linking it to storyboards is missing. The table indeed has over a thousand rows, but each row has no pointer to a specific dbvideo_process storyboard ID, so scene compositing still can't retrieve location data. So when checking, don't just look at row count—sample a few rows and confirm the storyboard ID field can link back. Are there counterexamples? Yes. Someone got clever and added a "location name" field to the places table, naming each row "palace," "city gate," etc., thinking it would be easier to identify. But the downstream scripts read a different description field; the name field became dead weight and did nothing. Someone else, to make the places table look clean, merged duplicate locations down to just thirty unique rows. Midway through the film's 1,029 shots, locations started jumping everywhere: one segment is at the palace, the next segment is still the palace, but the palace's orientation is different. Based on experience, this kind of scene chaos from insufficient places-table rows is the worst kind, because it's not random—it's a systematic error, and the only fix is re-running atctoscene across the board to rebuild all three tables. So don't merge, don't dictionary-ize—this point has been stressed repeatedly. Why is this design the way it is? Because its goal is enumerable, re-runnable, replaceable. If places were a dictionary table, you'd change one location name and every shot referencing it would need updating—a cascading, large-scale change that loses engineering control. But with one row per shot, each shot's location exists independently. You change one shot's location, and only that row moves; other shots are completely unaffected. The material's line, "swap an actor with one row edit, adjust a shot without redoing," makes exactly this point. Location replaceability works the same way: changing a shot's location description means changing that one row, re-running that one shot's composite, and leaving other records untouched. So the one-row-per-shot places table is the core embodiment of "turning creation into engineering" in this system. What's the immediate next action? Open your database, count how many rows are in dbvideo_places, then count how many rows are in dbvideo_process. Compare the two numbers—the difference tells you how big the problem is. If the places row count is clearly less than the process row count, take a few storyboard IDs that are missing location bindings and search them in the places table—nine times out of ten, they're absent. Pick two or three scenes you remember well, like the shot where the protagonist first appears, and check whether the corresponding places row exists and links back to the correct storyboard ID. After this step, you'll know whether you missed it, got it wrong, and whether you need to re-run atctoscene. Remember: the places table isn't a dictionary—it's the storyboard's shadow. And the shadow can't be shorter than its owner.