04-22-2016, 05:25 PM
I’ve been spending a lot of time in FrameForge recently, and one aspect of the product’s fundamental design is a constant source of frustration. It’s the set/shot paradigm itself. The issue can be summed up in this passage from the manual:
Whenever possible, make sure you position all the important set dressing before
storing any shots. This is because if you later go back to change a given stored
shot–to reshoot it from a higher angle, for example–the set will be restored with all
its cameras and objects in the exact state they were when the shot was first saved.
If at that time you hadn’t put in some walls or a character, those things won’t be
there when you go back, either.
That warning sounds innocuous enough to read, but in truth it’s impractical advice that goes against the realities of the creative process. The act of building sets and storing shots is highly iterative. That is certainly true if the final storyboard is to be high quality. No one can create a perfectly optimized set before beginning to use it and discover its flaws. In many days of use, I can’t tell you how many times I have had to replicate objects and settings across shots I've already snapped. Percolation is a blunt solution to this problem.
Furthermore in the current model, I feel that, the “set†object becomes useless, because it is SHOTS that end up holding the most refined properties and object states. After much use, when shots already exist I never start a scene from the master “setâ€. I start it from the most highly evolved shot, which likely departed from the set long ago. The offer to propagate shot changes to the set is not appealing, because I’ll never remember what they were, and many were actually shot-specific. It’s pointless.
I think the overall problem stems from two things:
1) The set/shot context model inadequately describes the real world, which is organized in sets (locations), SCENES and shots.
2) The actor/prop/set object property model does not provide persistent assignment and propagation to these contexts.
I realize that the following is an ambitious proposal, but I think FF will never work optimally until this object/property model is improved. So proposal:
A) Contexts are organized hierarchically as as project, sets, scenes and shots.
B) Objects exist in the project and the library.
C) Object properties, including visibility, wardrobe, positional, etc are ASSIGNABLE to either set, scene or shot, with reasonable default assignments:
- Set construction: SET
- Set sky and ambient lighting: SCENE
- Light fixture state: SCENE
- Character: PROJECT
- Character visibility: SCENE
- Character wardrobe: SCENE
- Character position: SHOT
- Camera: SET
- Camera position: SHOT
D) For any given shot, all object properties are read from the amalgam of set, scene and shot storage.
E) Any property changed in a parent context (e.g. Set), will appear automatically in its child contexts (Scene, Shot). Propagation is implicit.
F) If the user wants an object property to deviate within a lower context, the user can reassign the property category. E.g. “Make this boat's position a shot property. It’s drifting." Doing so copies the object’s global properties to all instances of the lower context (or using before/after logic as in percolation).
G) If the user wants an object property from a low context to be used in higher level context, the user can likewise reassign. E.g. "This extra should stand here for the entire scene". Doing so deletes the object properties from all instances of the lower context, and puts them in the higher context.
H) Creating a SET automatically creates a default SCENE. Creating a SCENE automatically creates a default SHOT.
With some consideration, you’ll see that with this system, you do not overwrite shots. In fact, a shot can be created as a placeholder in advance, and modified after the fact, with the ability to assign new objects or their states appropriately within the shot’s parentage (scene or set). There is no “re-shooting†a shot, and the paragraph from the user manual above is moot. It is a different paradigm.
This kind of system would make FrameForge a more powerful tool, simpler and quicker to use for real scripts. Here is an example case:
1) A scene: #1 EXT. PARK - NIGHT. A monologue with DAVE - 16 shots.
2) Then I want to add a light post.
3) A scene: #2 EXT. PARK - DAY. A monologue with Jessica - 18 shots.
4) Then I want to add fog to #1 EXT. PARK - NIGHT.
5) Then I want to turn the light post off for #2 EXT. PARK - DAY
6) Then I want to add some trees in the park.
7) Then I want #2 EXT. PARK - DAY to be cloudy.
8) Then I want every shot of DAVE craned lower, and JESSICA zoomed tighter.
9) Then I want to make the light post shorter.
I’m not sure how I'd do these in Frameforge today, but it would involve percolation, re-shots and possibly duplicated sets (as proxies for scenes). In the proposed model, I would:
- create a park set with 16 shots of Dave in the default scene
- create another scene with 18 shots of Jessica
- add a lightpost to the SET
- add fog to SCENE #1
- turn off the light in SCENE #2
- add trees to the SET
- change the sky to clouds in SCENE #2
- crane lower in SCENE #1
- zoom tighter in SCENE #2
- make the lightpost shorter in the SET.
Percolation would still exist in this model, but it’s use would be limited to duplicating actor/prop *action* across shots, since duplication of static elements like set pieces, fixed props and ambient conditions would be automatically propagated via set/scene inheritance.
Again, I realize that this is an aggressive proposal. I don’t need or expect an answer. I’m happy to talk about it more. Designing UI for object-oriented software was my previous 25 year career, so I understand the depth of the challenge, but also a lot about the solution.
If you read this far, wow, thanks.
Whenever possible, make sure you position all the important set dressing before
storing any shots. This is because if you later go back to change a given stored
shot–to reshoot it from a higher angle, for example–the set will be restored with all
its cameras and objects in the exact state they were when the shot was first saved.
If at that time you hadn’t put in some walls or a character, those things won’t be
there when you go back, either.
That warning sounds innocuous enough to read, but in truth it’s impractical advice that goes against the realities of the creative process. The act of building sets and storing shots is highly iterative. That is certainly true if the final storyboard is to be high quality. No one can create a perfectly optimized set before beginning to use it and discover its flaws. In many days of use, I can’t tell you how many times I have had to replicate objects and settings across shots I've already snapped. Percolation is a blunt solution to this problem.
Furthermore in the current model, I feel that, the “set†object becomes useless, because it is SHOTS that end up holding the most refined properties and object states. After much use, when shots already exist I never start a scene from the master “setâ€. I start it from the most highly evolved shot, which likely departed from the set long ago. The offer to propagate shot changes to the set is not appealing, because I’ll never remember what they were, and many were actually shot-specific. It’s pointless.
I think the overall problem stems from two things:
1) The set/shot context model inadequately describes the real world, which is organized in sets (locations), SCENES and shots.
2) The actor/prop/set object property model does not provide persistent assignment and propagation to these contexts.
I realize that the following is an ambitious proposal, but I think FF will never work optimally until this object/property model is improved. So proposal:
A) Contexts are organized hierarchically as as project, sets, scenes and shots.
B) Objects exist in the project and the library.
C) Object properties, including visibility, wardrobe, positional, etc are ASSIGNABLE to either set, scene or shot, with reasonable default assignments:
- Set construction: SET
- Set sky and ambient lighting: SCENE
- Light fixture state: SCENE
- Character: PROJECT
- Character visibility: SCENE
- Character wardrobe: SCENE
- Character position: SHOT
- Camera: SET
- Camera position: SHOT
D) For any given shot, all object properties are read from the amalgam of set, scene and shot storage.
E) Any property changed in a parent context (e.g. Set), will appear automatically in its child contexts (Scene, Shot). Propagation is implicit.
F) If the user wants an object property to deviate within a lower context, the user can reassign the property category. E.g. “Make this boat's position a shot property. It’s drifting." Doing so copies the object’s global properties to all instances of the lower context (or using before/after logic as in percolation).
G) If the user wants an object property from a low context to be used in higher level context, the user can likewise reassign. E.g. "This extra should stand here for the entire scene". Doing so deletes the object properties from all instances of the lower context, and puts them in the higher context.
H) Creating a SET automatically creates a default SCENE. Creating a SCENE automatically creates a default SHOT.
With some consideration, you’ll see that with this system, you do not overwrite shots. In fact, a shot can be created as a placeholder in advance, and modified after the fact, with the ability to assign new objects or their states appropriately within the shot’s parentage (scene or set). There is no “re-shooting†a shot, and the paragraph from the user manual above is moot. It is a different paradigm.
This kind of system would make FrameForge a more powerful tool, simpler and quicker to use for real scripts. Here is an example case:
1) A scene: #1 EXT. PARK - NIGHT. A monologue with DAVE - 16 shots.
2) Then I want to add a light post.
3) A scene: #2 EXT. PARK - DAY. A monologue with Jessica - 18 shots.
4) Then I want to add fog to #1 EXT. PARK - NIGHT.
5) Then I want to turn the light post off for #2 EXT. PARK - DAY
6) Then I want to add some trees in the park.
7) Then I want #2 EXT. PARK - DAY to be cloudy.
8) Then I want every shot of DAVE craned lower, and JESSICA zoomed tighter.
9) Then I want to make the light post shorter.
I’m not sure how I'd do these in Frameforge today, but it would involve percolation, re-shots and possibly duplicated sets (as proxies for scenes). In the proposed model, I would:
- create a park set with 16 shots of Dave in the default scene
- create another scene with 18 shots of Jessica
- add a lightpost to the SET
- add fog to SCENE #1
- turn off the light in SCENE #2
- add trees to the SET
- change the sky to clouds in SCENE #2
- crane lower in SCENE #1
- zoom tighter in SCENE #2
- make the lightpost shorter in the SET.
Percolation would still exist in this model, but it’s use would be limited to duplicating actor/prop *action* across shots, since duplication of static elements like set pieces, fixed props and ambient conditions would be automatically propagated via set/scene inheritance.
Again, I realize that this is an aggressive proposal. I don’t need or expect an answer. I’m happy to talk about it more. Designing UI for object-oriented software was my previous 25 year career, so I understand the depth of the challenge, but also a lot about the solution.
If you read this far, wow, thanks.