Does Swapping an Actor in an AI Film Really Take One Database Row?

Yes, it does. Change one database row and the character is recast across the entire film. Because a character portrait is a single row in the dbvideo_roles table—swapping actors means changing the character image field in that row. After the change, when all storyboards regenerate their images, the system automatically references the new image, and the old face no longer appears. This is what the material means by "swap an actor with one row edit, adjust a shot without redoing the whole thing"—for recasting, the entire system's design goal is to keep replacement cost as low as possible. Which row do you edit? The character's main image field in the dbvideo_roles table, also known as the rolex field. This field stores the character's electronic portrait ID. During image generation, the system uses it to call drawrole via Volcano Engine synchronous direct call to generate that character's image. Change the old value of rolex to a new one—say, from the old actor's portrait ID to the new actor's portrait ID—and all subsequent images of that character will use the new look. The material states it clearly: image generation follows three paths, and characters go through drawrole via Volcano Engine synchronous direct call. This path reads the current character's rolex field to run the generation. So the action of changing one row actually changes the source of every visual presentation of that character across the entire film. Nothing else—storyboard tables, prompts, scene compositing prompts—needs to be touched. What about old shots? Already-generated shots need to be regenerated, but you don't have to modify any prompts or scene records. For example, a character has 30 shots in chapter two, and every shot already has its first frame, last frame, and video generated. Now you change the rolex field. All 30 shots' first and last frames show the old face, so they must be regenerated. On re-run, the system reads the character ID in the storyboard record, looks it up in the dbvideo_roles table, finds rolex has been updated, and generates first and last frames with the new look, then drives new videos. Throughout the entire process, the character ID in the storyboard table hasn't changed, the location hasn't changed, the prompt template hasn't changed—only the portrait field in the character table has changed. Based on experience, re-running one shot costs a few yuan to about ten-plus yuan. Thirty shots can be fully recast for a few hundred yuan—far cheaper and faster than manually retouching faces frame by frame. Why is it this cheap? Because in the scene compositing prompt, fmpic directly references the character's current image. The material mentioned that scenes go through placeaiwords' character-present branch plus scenetopic for image-to-image compositing, where fmpic is the character image and plcpic is the location image. In other words, every shot's last frame or composited image pulls the latest character image from the character table at the moment of generation. Change the rolex field, and the next time scene compositing is called, fmpic automatically points to the new image, and the composite result is the new face. Conversely, if you don't change the character table but instead edit every storyboard's prompt, that's the disaster scenario—1,029 shots, each with a line like "actor Zhang San wearing red clothes" that all need to become "actor Li Si wearing red clothes." That's rewriting the entire film's storyboard prompts from scratch, a job that won't finish in under ten days to two weeks. So the root of the efficiency is that fmpic is a dynamic reference—it points like a pointer to the current record in the character table rather than storing a past snapshot. What pitfall do people most commonly step into? Changing only the character table while forgetting to clear the old first and last frame task records. Say you change the rolex field, then directly re-run video generation—and the resulting video still shows the old actor's face. Why? Because that shot's first and last frame images already exist locally or in the cloud. The system checks that the first and last frame status is completed, so it directly uses the old images to drive the video, never triggering the image-generation flow. What you need to do isn't change the character table; it's delete that shot's first and last frame task status, reset it to pending generation, or simply delete the old image files so the system re-runs the arcpictask image-generation prompt. Another trap: after changing the character table, you forget to sync the fixed descriptions in the prompts of every storyboard involving that character. The material mentions that process.aiwords is the eight-part skeleton of Jimeng video prompts, containing a "character information" section. If some shot's character information says "high nose bridge, big eyes," but your new actor has a round face and small eyes, the model may still be pulled astray by the prompt even after rolex changes, producing a hybrid face that's neither old nor new. So when changing rolex, also check whether the storyboards involving that character have hard-coded appearance descriptions, and update them if so. Are there counterexamples? Yes. Someone interpreted recasting as only changing the rolex field in the character table, but all character ID references in the storyboard table had already been extracted and stored separately in the project table. After the rename, nothing triggered an update—because the system was reading the copied character IDs in the storyboard table instead of doing a live lookup against the character table's primary key. Fortunately, the Yuncao Academy system doesn't make this mistake: its dbvideo_process table is designed to directly reference the combination of dbvideo_roles and dbvideo_places, re-querying on every run, so changes to the source table take effect. Another counterexample: someone tried to save effort by directly changing the character name in the dbvideo_roles table without touching the rolex field. The result: the displayed character name in all linked storyboard records changed, but the generated image was still the old look. That's changing the skin without changing the core. Remember: the character name is for humans; the rolex field is what the model sees. What's the real logic behind this design? It turns actors from "pictures" into "data." In traditional film, recasting means reshooting, because actors are pixels burned into celluloid. In an AI film, recasting means changing one row, because the actor becomes a database record whose fields can be replaced—and once replaced, every downstream link referencing it updates automatically. The material summarizes this as "breaking a film into enumerable, re-runnable, replaceable records," and recasting is the most typical scenario of "replaceable." You'll notice that nowhere in the entire system is a character image hard-coded into a storyboard—every shot's prompt references the character table via an ID instead of copying the appearance description into the storyboard table. That's why one row change recasts the whole film: the data exists once, and all shots share that single data source. What does this capability mean for the entire production workflow? It means you can iteratively try different actor looks before finalizing, without waiting until the whole film is done to discover the casting was wrong. Based on experience, I recommend: after storyboard splitting is complete but before large-scale image generation, test the rolex fields for your main characters—run the same prompt to generate several candidate looks, pick the best one, then batch-run. Because testing a character only costs one drawrole image—extremely cheap. But if you wait until all 1,029 shots are generated before recasting, you'll have to regenerate over a thousand first and last frames and over a thousand videos, doubling your costs. So this recasting capability isn't for putting out fires at the end—it's for polishing at the beginning. What's the immediate next action? Open your dbvideo_roles table, pick a character whose image you've already generated, change its rolex field to a different new portrait ID, then find any shot involving that character, clear its existing first and last frame status, and re-run arcpictask image generation plus Jimeng video generation. Based on experience, you'll see the new face appear in the first frame, last frame, and final output—while every other related record in the storyboard table stays untouched. Once you see this with your own eyes, you'll fully understand why "swap an actor with one row edit" is true. This experiment is cheap—just a few minutes and a few yuan—but it verifies the core design philosophy of the entire system: you've made the film into a collection of records, not a collection of images.