Two Essential Formulas That Eliminate Manual Work in Scene Composition and Storyboard Generation
Scene equals character plus location. On the surface, this formula looks like common knowledge from film theory, but when actually implemented into database logic, it produces an extremely strict constraint.
Every row in the dbvideo_process table must carry both a rolecode and a placecode. If either of these two foreign keys is missing, that row is not a valid shot.
Conversely, as long as a text segment contains both a character and a location, there is a high probability that a shot will be generated.
The core mechanism of the entire system is exactly this: running funx.atctoscene automatically in the background based on this formula, identifying the person names and place names in the text, and then deciding whether to generate a record.
This process requires no manual directing and no human judgment about which paragraph should be cut into a shot. It only follows one principle: whether the segment contains at least one character reference and one location reference simultaneously.
Let's break down the first formula in more detail.
Suppose there is a text segment: "Lin Xuan stopped at the foot of Cangwu Mountain and looked up at the boundary tablet."
In this sentence, Lin Xuan is the character, and the foot of Cangwu Mountain is the location. Since both character and location appear in the same sentence, the system determines that this sentence meets the basic conditions for generating a shot.
atctoscene scans the entities in the sentence, writes the character Lin Xuan into dbvideo_roles (or directly references the existing rolecode if the character already exists), and writes the location "foot of Cangwu Mountain" into dbvideo_places (likewise reusing the placecode if it already exists).
The system then generates a new process record using the sentence text along with the rolecode and placecode.
If the sentence is "Lin Xuan looked up at the boundary tablet"—with only a character and no location—the system will not generate a shot, because without a location, there is no environmental constraint for the visual.
If the sentence is "The rain at the foot of Cangwu Mountain gradually subsided"—with only a location and no character—the system will not generate a shot either, because there is no subject to perform an action or express emotion.
This constraint guarantees the validity of every storyboard record, eliminating empty shots and pure-scenery junk content at the data level, and also ensuring that subsequent image and video generation always have clear subjects and backgrounds.
The second formula further explains the specific way the storyboard table is generated.
dbvideo_process = dbvideo_roles dbvideo_places, meaning that in database operations, the data in the process table comes from a join operation between the roles table and the places table.
BODY:
In practice, atctoscene does not create the process table from scratch. Instead, it identifies characters from the article text and writes them into roles, identifies locations and writes them into places, then establishes a relationship between the two, combining a series of fields and inserting them into the process table.
A process record contains rolecode, placecode, articlecode, and the starting and ending line numbers of that shot within the text.
This effectively treats the roles and places tables as two dimension tables, with process as the fact table, recording each encounter between a character and a location within a specific chapter.
This design has a practical engineering advantage: it guarantees a consistent chain between storyboards and character/location data.
If you later need to modify a character's visual description, you only need to update the appearance field for that character in dbvideo_roles, then rerun drawrole to generate a new character image.
All process records referencing that rolecode will naturally pick up the new look, because arcpictask and placeaiwords look up the latest character information via the rolecode in process when generating images—rather than copying a snapshot of character data into process.
If the roles table were updated but process still stored an old text description, you would have to manually sync all historical shots.
The foreign-key relationship here completely avoids that inconsistency issue.
Similarly, when modifying a location's environment description, you only need to update the environment field in dbvideo_places, and all scene images referencing that placecode will automatically adopt the new environment background.
This process can be demonstrated intuitively with an SQL statement.
BODY:
Assuming atctoscene has already completed character and location recognition for a given article, the pseudocode for generating storyboard records is as follows:
INSERT INTO dbvideo_process (articlecode, rolecode, placecode, actiondesc, line_start, line_end)
SELECT a.articlecode, r.rolecode, p.placecode, e.action_text, e.start_line, e.end_line
FROM dbvideo_article a
JOIN (text entity event table) e ON a.articlecode = e.articlecode
LEFT JOIN dbvideo_roles r ON e.role_name = r.rolename
LEFT JOIN dbvideo_places p ON e.place_name = p.placename
WHERE r.rolecode IS NOT NULL AND p.placecode IS NOT NULL.
In this statement, the roles and places tables are joined via name matching, and a row is inserted into process only when both match results are non-null.
This condition directly implements the constraint of Formula 1 at the SQL level.
The logic running in the actual project is more refined than this pseudocode, because it also needs to handle disambiguation when the same character or location appears multiple times within a single text segment.
For example, across an entire chapter, Lin Xuan moves from the foot of Cangwu Mountain to the stone platform midway up the mountain, spanning three paragraphs. atctoscene determines shot boundaries based on location changes: as soon as the location field changes, it considers the previous shot ended and a new shot begun.
Similarly, if the character changes, that may also trigger a new shot.
So the final shot segmentation is based on changes in the combination of character and location, not on natural paragraph breaks.
This also further explains why a single chapter can be split into multiple shots—because the same pair of character and location can produce multiple records with different states, and these records are arranged sequentially in the process table according to the progression of actions in the text.
In the final film with 1,029 shots, every row can be traced back to a unique combination of character and location. Change one line for an actor change, change one line for a scene change, and all shots update automatically.
BODY:
This model turns storyboarding—traditionally a task that relies heavily on the intuition of screenwriters and directors—into a data-driven query and insertion process.
No manual thinking is required for shot language, composition, or camera movement; all of that is baked into the downstream prompt templates. Generating the storyboard table only requires ensuring that both a character and a location are recognized and present simultaneously.
In a sense, these two formulas are the most overlooked yet most important part of the entire pipeline, because they determine whether the data foundation for all subsequent image and video generation remains solid.
If a row without a character or without a location slips into the process table, the subsequent Jimeng generator will produce chaotic results due to the lack of a visual subject or background constraints.
By contrast, every row generated according to the formulas inherently meets the preconditions for generating an image or a video. That is the real significance of automated storyboarding replacing manual directing.