2025-06-17 Design: Story Tools

[dfelinto]

Attendees:

• Dalai Felinto
• Pablo Vazquez
• Falk David

Meeting to go over the project-related design requirements, or long standing design issues (i.e., design debts). Today’s topic: Story Tools.

Story Tools

• Dupli-copy vs Dupli-link
  • Add a new operator to Dupli Link (Alt+D).
  • Add a new preference option on “Copy on Duplicate”. (*)
    • “Strip Data”
  • Update Dupli Copy operator (Shift+D) to respect preferences. (*)
  • Add duplication options to the redo panel (Copy Settings, Linked Copy, Full Copy).

For now it means no functional change until users opt-in for this preference - i.e., Shift+D and Alt+D will behave the same. (*)

(*) - See the 5.0 Breaking Changes section for alternative approach.

5.0 Breaking Changes

The design above uses the same strategy used for the Node Tree group duplication (which also included no changes to users by default).

At some point (5.0?) we could change both defaults so Shift+D and Alt+D behave differently. Which also means both options (Node Tree and Strip Data) could also be removed from preferences.

For scene strips, we can also decide to go ahead and introduce the breaking change without the short-lived intermedium step.

Scene Assets

In order to re-use a scene as a start point for new scene strips we could introduce the concept of Scene Assets. Those scenes could be added from the Add menu.

• Allow users to make Scene Assets
  • From Scene Strip ID Template and outliner
    
    
• In the Add > Scene menu shows:
  • + New Scene
  • --- (separator)
  • CatalogName1
  • CatalogName2
  • --- (separator)
  • [icon] Unassigned
  • --- (separator)
  • Individual existing scenes.

Existing solution, that would need to be changed:

Usability

While looking at the Story Tools some general VSE UX issues were analysed. They will be presented in the next VSE module meeting.

Overlay: Name | Source

Existing problem: the ammount of information we have on the strip header is overwhelming:

• Source shows the entire path.
• The name of the strip and the name of the scene are both shown.
• Often times the scene strip name doesn’t matter (should just show the scene name).

The solution is to create something akin to the nodes, where Label allow for customization, while Blender can use heuristics for most cases.

The specific design was tablet for later (something Falk and Pablo would like to pick up and discuss with the rest of the VSE module).

Strip Camera

At the moment there is no way to know what is the camera being used by a scene strip (when no camera is assigned):

Proposal: To copy the UI/UX from the 3D Viewport:

[tintwotin]

@dfelinto

Overlay: Name | Source

Existing problem: the amount of information we have on the strip header is overwhelming:

• Source shows the entire path.
• The name of the strip and the name of the scene are both shown.
• Often times the scene strip name doesn’t matter (should just show the scene name).

The solution is to create something akin to the nodes, where Label allow for customization, while Blender can use heuristics for most cases.

The specific design was tablet for later (something Falk and Pablo would like to pick up and discuss with the rest of the VSE module).

The Overlay settings defaults should be just the Name, however the Text strip content text is written in the Source field, so before the defaults can be changed, the Text strip content should be displayed in the thumbnail/content area of the strip, same thing with scene strips, their content should be exposed as thumbnails. (Removing the Name will remove the strip type indication as string ex. Cross, Glow etc.)

@dfelinto

Strip Camera

At the moment, there is no way to know what is the camera being used by a scene strip (when no camera is assigned):

There is also the problem of the camera enum is displaying all the cameras of all scenes and not just the cameras of the scene selected in the Scene strip. So it’s easy to end up with the wrong camera.

All of these cameras are in different scenes:

[tintwotin]

Another Scene related thing: instead of an Update Scene Frame Range operator - the scene range should be exposed and be editable directly in the Time panel:

Also, the non-hold/hold range is not updated when the range of the scene used in the scene strip is updated (in the image the range on the strip is still 0-250, though it has been changed to something else).

The referenced Scene timings could also be exposed in the Time panel:

[Rockbard]

In the “old” VSE I’ve always wanted to see the original scene frames overlay

Why is it useful?
When you open the 3d scene of the strip to tweak some keyframes it sometimes hard to orient yourself as you don’t know how the current scene frames range and scene strip frame range aligns with each other.

For example:
Original scene frames 1-200
I mark 100 and 150 as start and end of the scene

In the VSE editor I further cut and move the scene strip on the timeline.

So at this point it’s really hard to track what frames of the original scene were used.

It would be cool to have the optional overlay text on the stip that will show the original frames numbers used looking at the current state of the strip.

[Rockbard]

And one more quick suggestion.

That would be so convinient to be able to switch to the selected strip’s 3d scene.

You select the scene strip, pressing “Tab”,
and you’re in the original 3d scene to make changes.
Press “Tab” again to go back to the VSE timelene