FrameForge Storyboard Studio Forums

Full Version: FrameForge object/context model
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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.
Wow, indeed. As I see it, the main problem with your proposal--aside from real technical issues--is that shots become too fluid, that changing something in your proposed hierarchy might have massive and unexpected ramifications in shots that you had already planned.

The main technical issue is that you can't simply "update" existing shots without re-rendering them so any change to your upper level hierarchy would, for all intents and purposes, have to be a percolation into existing shots, so you're not really saving any time nor really getting any new control.

While I can't discuss the details, we do have an alternate solution which I think you will really like, though it is still some ways off.

We really do appreciate your thoughts and the productive way in which they were presented.
Thanks for replying. I think that if you were to suspend disbelief for a while longer, you would realize solutions to the problems you envision.

Quote:changing something in your proposed hierarchy might have massive and unexpected ramifications in shots that you had already planned.
I agree with "massive", but not with "unexpected". I think the current model produces unexpected results precisely because there is no explicit context model. So long as the user is working from a clearly organized plan, aka, script, a rigorously rational context model should make the massive change perfectly and pleasantly expected. The semantics of my case solution walkthrough should illustrate that. Try to describe the steps that would accomplish the same case using the current model. The semantics of that solution have nothing to do with literary organization.

Quote:you can't simply "update" existing shots without re-rendering them
To be accurate, I would say you can simply update shots without percolating their *rendering*. In practical terms, the rendering of dirty shots is negotiable. This generic problem is handled by many products in many ways. One is to mark dirty shots visually and update lazily, on-command, just-in time, on intervals, etc. It's an optimization problem.

Quote:not really saving any time nor really getting any new control
This marginalizes the actual benefit of the system. Agreed that net rendering time is the same. But the proposal is about user workflow and the mental and physical modeling of sets and scenes. The current system is hard to use for complete scripts because the system lacks the organizational constructs of a show/script. To lack those *things* is to lack a direct way to change those *things*. If this doesn't make sense, try performing my example case above mentally with the current system, or better yet a 30 minute script with 10 locations and 50 scenes. The arcane machinations involved in fluid iteration are mind-boggling (to a user).

Quote:we do have an alternate solution
If you are interested in a customer-centric approach to product design, I'm happy to be one of those customers.

Thanks again.
We'll definitely discuss it more in-house but, to be fair, we have had many, many complete films and TV shows previsualized using FrameForge to great success. So, while I appreciate that the program's work-flow may not be optimal for the way you work and think, I feel that the solution you propose would not be the most intuitive to many of our other users.

In any case, our future versions will offer other options for workflows, including one which I am sure resolve most of your issues in a simpler, more direct manner. However, I can't say more beyond that at the moment, nor can I offer a time-frame though we'll definitely keep you in mind for a beta tester when we get that point.

I will leave you with one immediate suggestion though. In your proposed sequence you had two dramatically different scenes in the same "set." What we'd recommend in that case is that you shoot the first sequence (the night shots) and then clone the set for a day shoot and then you have two versions, each with the same basic set dressing but which can be percolated separately and given dramatically different lighting and object states.
Quote:We'll definitely discuss it more in-house but, to be fair, we have had many, many complete films and TV shows previsualized using FrameForge to great success.
Please don't be defensive. I'm not trying slam FF or say it can't be used. I bought it, I'm using it, and I will be successful too! I am only proposing that it can be improved to the benefit of customers, even those who are successful with it today. I think that to say something is already perfect and can't be improved denies the possibility of progress.

Also, we all know that every one of those TV and film scripts had scenes, and that the "scene" word and concept was considered, uttered and applied thousands of times while building those previz's, all with FF's passive denial that scenes exist, by evolution, as the dominant construct of theater, film and television organization.

Quote:the solution you propose would not be the most intuitive to many of our other users.
Respectfully, I think this is self-limiting in two ways:

1) To think that one's own point of view can substitute for the customer's is to deny we have any unique orientation or perspective. The only reliable way to know what customers think is to ask/research/test customers. Any design endeavor that omits this step replaces science with self projection. So, yes, I too may be wrong about this proposal, but then again, I am an actual customer providing genuine input. The only way to know if there are more like me, would be to faithfully and objectively inquire. I say "inquire" because "ask" is only one blunt method of user inquiry.

2) It's impossible to claim or measure intuitiveness of an experience without hypothesizing and presenting physical designs. To say "would not be the most intuitive" is to claim one has already exhausted the design possibilities that would make it intuitive. It is to say that ethnography, prototyping and usability testing have no role in excellent design. It's to say that anything better is impossible, which when wrong, is a failure of imagination.

Quote:future versions will offer other options for workflows...keep you in mind for a beta tester
For the sake of Innoventive and customers, I would urge that you test and iterate new concepts and designs with customers before time-consuming and expensive implementation. Doing so is easy, and monumentally informative to good design. All it takes is 6-8 customers, paper prototypes, and an open, objective mind.

I would also urge that Innoventive conduct a brief "come to reality" usability research session where a few new and existing users are asked to perform tasks using think-aloud protocol, and objectively observed and documented. The purpose of the process is to jarringly replace developer projection with customer truth. I can assure that such a study will reveal severe usability hot-spots and opportunities for significant improvement.

Quote:clone the set for a day shoot and then you have two versions
Of course I understand I can do this. I am asking Innoventive to consider that duplicating an entire set and forever synchronizing changes to either, all for the purpose of alternate lighting, is unfortunate and is unnecessary for lack of "scene".

Btw, there's an analogous discussion regarding actors, characters and costumes. And also btw, I am grateful for Poses.

I want to take this opportunity to apologize for being so aggressively direct and probably pedantic. I do it selfishly in that I want the product I know FrameForge could be, and I have the professional experience to know how one gets there. Of course it's all your business.

Please accept my humble appreciation for FrameForge. It has been immensely useful to my current project, and I know no other that I'd prefer to use.

Thanks again.
For once I actually agree with Steven. His approach to boarding is much more cinematic with regards to sets. However, I think Ken has a very elegant solution. I use it frequently.
After more work in FF, it occurs to me that this proposal lacks an important construct, and that is Action distinct from shot.

Once a sequence has been created to embody actor and prop motion, one would be able to author camera motions "on top" of that sequence without having to explicitly define camera settings and movement for every intermediate pose.

Example:

1) For two actors, create a sequence of 20 poses, including duration, dissolve and tween parameters - all constituting a unit of "action" (e.g. dialogue).

2) Set cameras and "shoot" the pre-determined action by altering and storing camera settings, position, duration and tweens of camera "shots".

3) Alter the shots to maximum effect without having to alter or revisit the actor action already defined.
From another post...
Quote:Wow. That is lot to read. However, I'm a little confused by one passage.

3) A scene: #2 EXT. PARK - DAY. A monologue with Jessica - 18 shots.
4) Then I want to add fog to NIGHT.
5) Then I want to turn the light post off for DAY

I understand how you want to change the weather and time in a scene, but I don't understand the reason why. Are you changing the conditions of the scene to experiment with how the scene might feel with different weather or at different time of day?
Those are just examples of wanting to change anything within a scene, after the fact. I've clarified the original post. It's:

4) ..add fog to scene #2 EXT. PARK - NIGHT
5) ..turn the light post off for scene #1 EXT. PARK - DAY

Adding fog could be an experiment or simply a decision to change the environment or the look. Turning the light post off could simply be that I previously forgot and left it on.

They're examples among a multitude of possible changes one might want to make to lighting, cameras, props, within a scene.