Christophe, I have an old windows svg editor "webdraw" from jasc Software. It has SVG animation integrated. Once I have time I will do some snapshots if that helps. pls remind me in case I forget ;-) HTH, Adib ---

On Mon, Mar 10, 2008 at 2:38 PM, Christophe Dehais <christophe.dehais@...400...> wrote:

Hi all !

Replying to myself to let you know that I started putting some notes about SVG Animation on the wiki:

http://wiki.inkscape.org/wiki/index.php/SVG_Animation

For the most part it's nothing more than a rewording of the SVG spec in more informal language. And it's still a work in progress. Comments and corrections welcomed !

Next time, I'll try to add a page with some UI ideas.

cheers, Christophe

On Sun, Mar 2, 2008 at 7:45 PM, Christophe Dehais <christophe.dehais@...400...> wrote:

...

Hi Martin and everyone!

On Tue, Feb 26, 2008 at 9:56 AM, Martin Owens <doctormo@...400...> wrote:

...

If anyone is looking for a small simple project that would make great impact they should think about working with me on the simple animation plan; although I've not had a lot of time to work on it other than reading inkscape codebase, I do believe the plan to be a solid starting point.

I might actually be interested in this. I don't know what you have in mind precisely about "the simple animation plan", but here are the main possible goals I see:

• implement the svg animation elements : animate, set,

animate{Motion|Color|Transform}

• figure out a decent UI for editing animations:
  • a time-based (SMIL oriented) timeline editor to represent / move

around keytimes (=keyframes except it's not frame-based but time-based)

• an interpolation curves editor

• design some animation-related on-canvas items, like:
  • trajectories (motion-paths)
  • temporarily overlayed (t-epsilon) / (t+epsilon) state of an

object (to mimic onion skinning)

Is that close to what you thought about ?

There are a lot of open questions, like:

• should there be an "animation mode" where the animated attributes

values are edited, as opposed to a "normal mode" where it's the object attributes that are modified ?

• SMIL semantic is quite rich: at first some things might be discarded

like repetition or the possibility to define the start of an animation based of some events (e.g. user click or the end of another animation). Those things don't map well in a timeline UI which I guess is the way animators are used to think.

• will the canvas scale well to preview large animations sufficiently smoothly ?

Comments welcomed !

regards, Christophe

---

This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Martin Owens wrote :

...

Hi Martin and everyone!

Hi there, sorry for the delay in getting back to you.

...

I might actually be interested in this. I don't know what you have in mind precisely about "the simple animation plan", but here are the main possible goals I see:

Not quite, your solution would be a rock solid implementation (or the start of one) what i have in mind is much simpler and is mainly enabling:

Step 1 - Code change to add a slide bar which when enabled quickly switches between layers, causing other layers to be invisible/not editable. This has a benefit on static artists too. Add option for causing the +1 and/or -1 layer to be semi transparent.

That's a great onion skin addition to Inkscape's GUI. Note that animators often work with more than -1/+1 layer visible - it would be nice if it's possible to chose the number of layers (like -2/+1, or -10/+10) since it's quite useful for non linear-speed moves (like an object falling/bouncing, or a simple walk motion)

Step 2 - Write a python based plugin to take the current layer and copy verbatum the layer into a new layer for tweening.

Great since this could be a workaround for backgrounds. If Step one is customisable, it might be possible to select a few layers that would always appear (background/foreground) to save speed during editing (less objects than redrawing the same background 3 or more time with transparency on 2 or more layers.

Step 3 - Write a _very_ forgiving plugin which outputs an animated svg based on each layer being a keyframe.

This produces some simple animation for us and wouldn't take long to do and wouldn't even change the code base very much and the gui changes are benificial to non animation editing too.

You may or may not want to add to the plugin the ability to control the keyTimes for the keyframes.

These are some nice features to look forward to if the SoC project is accepted. I've been toying with the idea to write a blueprint for basic onion skin animation support in Inkscape, but didn't know if it was just asking too much. Animated svg looks really promising.

Loïc

Not a problem,

Unfortunately tackling the foundations of a rock solid implementation is the core motivation for me. I'd like to have the basis for a very general SMIL implementation, that could possibly handle any animatable attributes.

Doing a solid implementation is attractive, it'll take longer though. Just make sure that you have these abilities:

1) To take the current and next keyframes and move between them, displaying the tweened result at any given time. 2) To create a new key frame from a tweened (i.e. not really there) frame by editing it (make sure to display in your timeline where all the keyframes are) 3) You'll also need to be able to play animations in inkscape which would be interesting to see since I've yet to come across one that was fast enough. 4) Make the UI simple, only use ideas from existing animators if it makes sense to do so. You want to remove most of the complexity from the user and allow them to edit that complexity at their will.

I know from editing animated svg files that it's a very interesting task, even in a text editor; the most interesting animation abilities to me are animating paths since they're the hardest to visualise and the most interesting to tween.

Best Regards, Martin Owens

On Wed, Mar 12, 2008 at 4:27 PM, <J.B.C.Engelen@...1578...> wrote:

If I read your intentions correctly, you should not aim to get something working :) (not fully at least).

Yes, being fully SMIL compliant at the end of the summer seems quite unrealistic. But I think "the backend" part of the implementation should be made in a general enough way to support everything in the end. For the UI part, the work maybe more experimental.

What for GSoC is possible, I think, is:

1. Make Inkscape not forget svg animation attributes (basically make the SPObject thingies that are already present for svg:rect svg:path svg:g etc but then for svg:animation). Don't let the objects do anything :) because that alone would mean more than one GSoC project I think. Perhaps Inkscape already doesn't 'forget' the attributes, that'd be awesome, and then this step vanishes.

Inkscape seems to keep the attributes around already. For the experiments I posted on the wikipage, I used the XML editor to add the animation elements by hand. They're saved along the rest of the file. Animation elements are not bound to runtime objects though, so yes creating those representations is the first step (actually there is a (not compiled?) sp-animation.cpp stub in the codebase). Then animatable attributes should gain the notion of 'presentation time value', controlled by the current (stack of) animation applied to them.

2. Make simple UI to edit svg animation attributes. Onion-skinning etc sound like a GSoC project of their own! Really, it depends on how much time you are going to invest, but have a look at the size of last year's gsocprojects. Probably the simplest you can come up with is already enough work! So perhaps you could pick one part of animation attributes UI and make something for that. (i.e. only make the timeline UI, with enough simplicity and complexity)

Indeed the timeline UI in itself is quite some work I guess. Maybe just implementing the motion path on-canvas helper with onion skinning simulation could be more reasonable for this period of time.

Now that I think of it, it would have helped me to have an LPE editing mockup before I started. (more precise than what I had in my head) So perhaps you should (like you already did) start gsoc with as precise a UI description as possible. (for example also, who writes to XML, what will be written to XML, which XML changes should trigger an update of which widgets, etc...

That's seem a good plan of action. I'd like to avoid proposing something that turns out to be a dead-end for future improvements (toward full SMIL compliance), So a careful analysis is definitely good. And making mockups would help getting feedback from animation-aware users.

Cheers from a fellow GSoC2008 aspirant, Johan

thanks for sharing ideas!

Cheers, Christophe

On Wed, Mar 12, 2008 at 04:58:36PM +0100, Christophe Dehais wrote:

On Wed, Mar 12, 2008 at 4:27 PM, <J.B.C.Engelen@...1578...> wrote:

...

If I read your intentions correctly, you should not aim to get something working :) (not fully at least).

Yes, being fully SMIL compliant at the end of the summer seems quite unrealistic. But I think "the backend" part of the implementation should be made in a general enough way to support everything in the end. For the UI part, the work maybe more experimental.

Indeed, another limiting factor for this year's GSoC is that we would like to avoid things that require significant internals change, as we'll be doing some serious refactoring of that this summer.

So I'd agree to aim this project in a way that generates something that is more of a demo/proof-of-concept, and avoids significant investing effort into integration into the core (since it'd likely have to be redone anyway.)

Bryce

On Mon, Mar 10, 2008 at 02:38:12PM +0100, Christophe Dehais wrote:

Replying to myself to let you know that I started putting some notes about SVG Animation on the wiki:

http://wiki.inkscape.org/wiki/index.php/SVG_Animation

See

http://wiki.inkscape.org/wiki/index.php/Animation

for links to some existing pages concerning animation on our wiki. That URL is intended to point to all animation-related pages; please either edit that page to point to one or more of your new pages (takes only a minute), and/or (taking longer) merge your pages with the existing pages. I'm sure you'll at least want to read those pages, and you may well want to add comments or links to your new pages even if you don't want to do a full merge yet.

Thanks for thinking about these things,

pjrm.

hi in some way animation can be done through java scripting (and not just for motion & shape tweens... interactivity is cool) i'm going to be off of this mail's topic there sorry, does someone know if there's any svg javascripting plugins/dialogs in inkscape ? For not much is needed to be able to do basic scripting the Actionscript way, but for SVG : put code over or inside objects to control them, to override these objects' event methods. I don't know svg much, but one way further to animate object properties, instead of using the builtin tweening svg capabilities, is to have script drivers (like python drivers for Blender IPOS (keyframes)) : expressions that are shorter than a piece of code, and return some value to use. For example, assign to the alpha of some object the java script expression : sin(2*3.14*10*_current_frame_number) where _current_frame_number is the official frame number is a variable representing the actual frame being played in the running svg animation/application.

Jonathan

On Wed, May 7, 2008 at 6:19 AM, Peter Moulder < Peter.Moulder@...38...> wrote:

On Mon, Mar 10, 2008 at 02:38:12PM +0100, Christophe Dehais wrote:

...

Replying to myself to let you know that I started putting some notes about SVG Animation on the wiki:

http://wiki.inkscape.org/wiki/index.php/SVG_Animation

See

http://wiki.inkscape.org/wiki/index.php/Animation

for links to some existing pages concerning animation on our wiki. That URL is intended to point to all animation-related pages; please either edit that page to point to one or more of your new pages (takes only a minute), and/or (taking longer) merge your pages with the existing pages. I'm sure you'll at least want to read those pages, and you may well want to add comments or links to your new pages even if you don't want to do a full merge yet.

Thanks for thinking about these things,

pjrm.

---

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2.

http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

I've seen several people mention Shockwave-style animation, with something like the Score. I wonder if people know about this spec yet, which layers such a model atop SMIL: http://www.w3.org/TR/timesheets/

This would be a way to go, if such a thing is desired. It's always best to avoid adding new and incompatible namespaces.

By the way, while trying to implement SVG-DOM in /src/dom and binding/scripting int /src/bind, I am finding a lot of questions that are not, as far as I can find, in the specs.

For example, the interfaces here, except for SVGElement, do not inherit from Element, thus do not have attributes: http://www.w3.org/TR/SVG/types.html#BasicDOMInterfaces ...yet they all must map their semantic values onto attributes when getting/setting. Is there a reason for that? It would seem to be more efficient to inherit this, along with their semantics.

Would anyone know why? Just curious. This seems to demand an interface/implementation split, rather than merely suggest it.

bob

Chris Lilley wrote:

On Wednesday, May 7, 2008, 6:48:59 AM, Jonathan-David wrote:

JDS> I don't know svg much, but one way further to animate object JDS> properties, instead of using the builtin tweening svg JDS> capabilities, is to have script drivers (like python drivers for JDS> Blender IPOS (keyframes)) : expressions that are shorter than a JDS> piece of code, and return some value to use. For example, assign JDS> to the alpha of some object the java script expression : JDS> sin(2*3.14*10*_current_frame_number) where _current_frame_number JDS> is the official frame number is a variable representing the JDS> actual frame being played in the running svg animation/application.

SVG isn't frame based (perhaps you are more familiar with SWF?) but a relative time-based expression would be one way to do this.