- a reference the underlying asset
- the offset into the underlying asset at which the object starts playing
- the scene-time at which the object appears
- a stream of parameter change events (probably with some kind of index for chronological search when in memory)
- the duration of the object's appearance in the scene (which may be shorter or longer than the duration of the parameter change stream)
The design and implementation of an Open Source animation tool.
July 21, 2007
Scene and Sequence Representation
Mike convinced me early on that we should aim for representing scenes and sequences as streams of events to the extent possible; however, there is a tradeoff involved because a stream (particularly a stream of deltas) is not an efficient representation for random access which is often a requirement in an editor. My feeling at the moment is that the best approach is to store each object separately, an object consisting of:
Labels:
implementation,
parameters,
scene,
sequence
Subscribe to:
Post Comments (Atom)
2 comments:
Oh, yeah, I wasn't saying we should literally store it event stream style. Well, maybe I was :)
Regardless, I think its more that the display needs to be somewhat like this.
Your plan sounds good!
We might stick this animation data in groups in files (I guess it'd go in the scene asset!), though. It can get pretty annoying to have a directory with 2000+ files in it. File managers just weren't made for it.
The animation data for a scene would all go in the scene asset, yes.
That said, we're still going to have a lot of files with individual assets laying around -- but that's the motivation for the asset pane, really. It picks up the slack for the file manager.
Post a Comment