Storyboard-Driven Filmmaking: Swapping Actors with One Database Row Update

Suppose you are producing an AI film titled *The First Avenue*, starring a protagonist named Lin Xuan, initially portrayed by the parameters of virtual actor A. The film has already completed first- and last-frame generation for all shots and video segment rendering. Suddenly, you decide to recast, bringing in virtual actor B to play Lin Xuan. In traditional film production, this means reshooting every shot that contains Lin Xuan—at least two hundred storyboard scenes are involved. Each shot requires reconfiguring lighting, adjusting camera positions, and having the actor perform again, pushing the entire recasting cycle to at least two weeks. But in Yuncao Academy's engineered system, you only need to modify one row in the `dbvideo_roles` table, changing the `actor_name` field for Lin Xuan's record from A to B, then mark all generated first- and last-frame images as pending regeneration, and re-run the image generation task. Every storyboard among all 1,029 shots that references the character Lin Xuan is automatically identified by the system and regenerated, with the entire process taking no more than three hours.

The foundation of this miracle lies in the rigorous foreign key relationship between the character table and the storyboard table. The `rolex` field in the `dbvideo_process` table is a string-type foreign key that stores the primary key `rolecode` from the `dbvideo_roles` table. When you execute the statement `UPDATE dbvideo_roles SET actor_name = 'B' WHERE rolecode = 'ROLE_LINXUAN'`, there is no place in the system that needs to synchronously update data in the storyboard table. Although as many as several hundred records in `dbvideo_process` have `rolex` pointing to the same character row, these records themselves do not need updating. Because all fields that need to change—including character appearance description, eyebrow shape, eye shape, facial contour, and clothing style—are stored in the `role_desc` column of the `dbvideo_roles` table. The prompt construction logic during image generation is to first read the latest character appearance description from `dbvideo_roles`, then fill it into the single variable position for character information in the `process.aiwords` template. So when you change one row in the character table, the next round of image generation tasks automatically pulls the new actor's appearance parameters from the character table.

The key to this design is that first- and last-frame image paths are not stored directly in the `dbvideo_process` table; instead, they reside in the `dbvideo_arcpictask` table. Each row in that table records one shot's image generation task, containing `taskid`, `scenecode`, `rolex` reference, `firstpic` path, `secondpic` path, and `taskdes` prompt. The `taskdes` field is a string dynamically concatenated at image generation time, embedding the current actor's latest appearance description. When you modify structural data in `dbvideo_roles`, the system detects that the character's `lastupdated_time` timestamp has changed, automatically triggering a pre-built update trigger in the database that regenerates the `taskdes` field for all `arcpictask` records referencing that character. Specifically, the trigger re-invokes the prompt-generation function, reads the new appearance description, and replaces the old character description fragment in `taskdes`. Simultaneously, the system automatically clears the content of the `firstpic` and `secondpic` fields, sets the image paths to empty values, and resets the task status to `waiting`. As a result, when the image generation client scans for tasks with status `waiting`, it re-invokes the `drawrole` function to generate new first and last frames using the new actor parameters, saves them to paths, and then writes those paths back into `arcpictask`. The entire flow requires no manual intervention and no SQL statement changes—it is a cascade update triggered by a single `UPDATE`.

More elegantly, this modification has the same effect on video prompts. The `aiwords` field in the `dbvideo_process` table is the input text for the Jimeng video generator, where the character information slot directly references the character description from the character table. Once the character table field is updated, the system can verify its impact with a standard SQL query: `SELECT COUNT(*) FROM dbvideo_process WHERE rolex = 'ROLE_LINXUAN' AND status = 'done'`—this statement returns the number of storyboards that have already generated videos and reference Lin Xuan, say 231. At this point, you reset the `status` of these storyboards to `ready`, and the video client automatically loops through these tasks, resubmitting the refreshed `aiwords` to the Jimeng generator. Because it operates in image-to-video mode, the first frame images are also newly generated, so the actor's appearance in the final videos naturally changes. This entire chain of reactions is driven by the database's relational mapping mechanism, with no business code modified.

Throughout this process, the `blu` and `blp` functions serve as critical routing roles. When the system runs within the same world environment—say, the First Avenue world—the `blu` function returns a database connection pointing to Yuncao Academy's local database instance, and the `blp` function returns `dbvideo_` as the table prefix. At this point, all table lookups occur on the `dbvideo_roles`, `dbvideo_process`, and `dbvideo_arcpictask` tables in the primary database. But when you clone the entire production process to another world environment, such as the Fukangan world, the return values of the `blu` and `blp` functions change: `blu` points to a different database instance, and `blp` returns a different prefix. At this point, modifying the row for Lin Xuan in the `dbvideo_roles` table automatically limits its impact to the database tables within the Fukangan world, leaving the First Avenue world data completely unaffected. This isolation allows multiple worlds to run different actor plans in parallel—you can use actor A in the First Avenue world and actor B in the Fukangan world, with the same character code having different actor configurations across the two worlds.

Compared with traditional film production, the cost advantage of this data-driven recasting model is on an order of magnitude. In traditional production, recasting means reshooting because the actor's physical presence is attached to the film. But in Yuncao Academy, an actor is merely a database record—more precisely, a collection of character attributes. The essence of recasting is changing the value of the character appearance description field from actor A's set of skin texture and facial proportion parameters to actor B's set of parameters. The process is fully reversible—you can even store two sets of parameters for different actors simultaneously and use another field, `control_flag`, to switch which one is currently active. This adds a possibility over traditional methods: gray release of a new actor, letting the new actor go live on ten shots first, comparing the results, and then switching across the board.

It is also worth noting that this maintenance convenience is not limited to the recasting scenario. When a director feels a character's face is too squared, they only need to modify the `face_ratio` field in `dbvideo_roles`, changing it from 0.85 to 0.92, and then regenerate the first- and last-frame images referencing that character—the entire character appearance receives a fine adjustment. When you want to replace an entire scene, modifying the `geometry` description field for the corresponding `placecode` in `dbvideo_places` means all storyboards referencing that location will automatically generate new backgrounds on the next image generation pass. Therefore, the entire production maintenance flow becomes a series of database `UPDATE` statements, with each maintenance action enumerable, rollbackable, and repeatable. Even if you recast incorrectly, you can restore the previous snapshot and re-run the update task. This is the core value of data-driven filmmaking: creation is no longer an irreversible manual process but an engineering artifact that can be version-managed. This enables one person to accomplish what previously required a team's recasting workload—reduced to a pure database operation, using only the row-level update mechanism that already exists in the Yuncao Academy system.