This is an attempt to breakdown the larger SMIL problem into dependent pieces of work and also define a test which can say if this piece is done. What piece would you like to work on the most?
If you can see any gaps or better delineations, we can modify:
1. Preservation - Allow all SMIL elements and attributes to exist in loaded documents and save them back without modifications even if the object's they're tied to are modified. The test is a set of SMIL enabled animations and this might already pass.
2. Propertise - Actually load SMIL elebutes into structures and make them accessible via code. The test would be a code test, call out all the attributes and iterate over times.
3. Internal Time Line - We'd introduce the time dimension to our objects and we'd be able to set a time on them and read back nearest values (no interpolation). The test would be another code test to select objects, set a time and read back attributes. (getAttributeAtTime?)
4. Static Time - We'd allow the user to set a time via the ui or the command line and render that as a static non-animated drawing. The test would be a visual one, load inkscape with an existing smil svg file and pick a bunch of times and export each as a png frame.
5. Interpolation - This can happen along side any other pieces after 3, but it's a well understood problem and testing can be done with either a code test requesting attributes non-key-frame times or a visual test like 4 for non-key-frame times.
6. Renderer - We attempt to create a smooth animation from the attributes. This involves automatically progressing over time and changing the rendered output. The test would be to load a smil svg and see the animation animate on canvas once. (Play button/keycombo?)
7. Timeline UI - This is the most UI design aspect. We add in a way for the user to move through the timeline. We don't have to make the UI look like any existing products. The test would allow a user to drag through a timeline, press pause, start, etc and see the result.
8. Attribute modification - This is where it changes from being a viewer to an editor. Moving and changing attributes while at a specific time can create the required key frames in a linear time progression. Deleting those key times would be useful too. Test would be to create a simple animation from scratch.
9. Export - This is where we save out frames from the render one by one into a desired format. The test is simply the ability to get an mpeg or dir of pngs from an smil svg file.
These steps are all really basic and each one should be non-intrusive and capable of being released without effecting the experience for static artists.
The next question is; if we were to organise a project around these tasks; how far would we initially go and how much would each step cost?
Best Regards, Martin Owens
El lun, 02-12-2013 a las 15:36 -0500, Martin Owens escribió:
Hi Martin thanks for the guide
I have a big cuestion... Whats the goal of our SMIL implementation Create a package for multimedia authoring. Director, Flash... Or a animation ones. Synfig, Moho...
And some comments to the guide but not focused in testing :(
- Internal Time Line - We'd introduce the time dimension to our objects
and we'd be able to set a time on them and read back nearest values (no interpolation). The test would be another code test to select objects, set a time and read back attributes. (getAttributeAtTime?)
Time dimensions to objects or points? I read a bit the logic is to objects -points by interpolation- but think is interesting put here.
- Static Time - We'd allow the user to set a time via the ui or the
command line and render that as a static non-animated drawing. The test would be a visual one, load inkscape with an existing smil svg file and pick a bunch of times and export each as a png frame.
If there is a multimedia action objects like "Click and play"? How to know if need render in a specific display/print surface. Maybe is to avanced at this point of the process.
- Timeline UI - This is the most UI design aspect. We add in a way
for the user to move through the timeline. We don't have to make the UI look like any existing products. The test would allow a user to drag through a timeline, press pause, start, etc and see the result.
I like two timelines, general timeline and selected item timeline -unique. Ability to put actions inside frames?
The next question is; if we were to organise a project around these tasks; how far would we initially go and how much would each step cost?
Think all points are necesay to take something usable. I always fail in second point ;), but time, money, number of devs,coverture of the implementation... are welcome to go wrong
Best regards, Jabier.
On Mon, 2013-12-02 at 23:37 +0100, Jabiertxo Arraiza Cenoz wrote:
Whats the goal of our SMIL implementation
There's a dual goal; firstly to support more of the svg specification which is inkscape's long term goal. And secondly to provide a practical interface for dealing with animation.
It's that second part that needs the UI thinking. Because having inkscape always animate would take away from static drawing.
But for now I'm happy to see some of the under-the-hood points be fixed so that inkscape can deal with SMIL, even if it's not a great editor for it.
Martin,
participants (2)
-
Jabiertxo Arraiza Cenoz
-
Martin Owens