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

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.

OK I see.

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. The other motivation is to dive into Inkscape codebase in order to learn it, so the plugin approach doesn't appeal much to me. Also I may be wrong but the plugin approach is kind of limited regarding the UI that can be added to Inkscape (see [1] for I'm thinking about) I won't deny that your proposal seems the quickest path to have something working.

As for a GSoC proposal, I'd try to narrow the goals to some simple objectives and maybe write a blueprint.

cheers, Christophe.

[1] http://wiki.inkscape.org/wiki/index.php/SVG_Animation_UI

On Mon, Mar 10, 2008 at 3:11 PM, Martin Owens <doctormo@...400...> 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. Step 2 - Write a python based plugin to take the current layer and copy verbatum the layer into a new layer for tweening. 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.

This would allow you in a sense to save the document as a normal static svg and a compiled animated svg with different output.

We would be leaning on SMIL which means it won't work in Firefox 2, but will work in adobe svg viewer and mostly work in Opera if you want to test it.

Join me on irc for more chatting.

Best Regards, Martin Owens

-----Original Message----- From: Christophe Dehais [mailto:christophe.dehais@...400...] Sent: woensdag 12 maart 2008 12:18 To: Martin Owens Cc: Engelen, J.B.C. (Johan); jon@...235...; bryce@...1798...; john.cliff@...400...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Animation (was: Re: Inkscape / GSoC '08 proposal)

OK I see.

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. The other motivation is to dive into Inkscape codebase in order to learn it, so the plugin approach doesn't appeal much to me. Also I may be wrong but the plugin approach is kind of limited regarding the UI that can be added to Inkscape (see [1] for I'm thinking about) I won't deny that your proposal seems the quickest path to have something working.

As for a GSoC proposal, I'd try to narrow the goals to some simple objectives and maybe write a blueprint.

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

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.

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)

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...

Cheers from a fellow GSoC2008 aspirant, Johan

On Mar 12, 2008, at 8:58 AM, Christophe Dehais wrote:

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.

Also if you're looking at a solid back-end, remember that there are *two* main ways to do animation in SVG. There is the declarative SMIL style animation, but then there is also animation driven by scripting such as Javascript. It's also very possible to mix the two. Also given that Bob has gotten some big jumps in scripting and DOM coming along, there is a higher chance of needed internals being there. Also for web browsers the scripting route, or at least supplementing with scripting, is a very common one.

I think that a first-pass UI might allow for a pane to preview change curves, basically a simple timeline showing curves like on the wiki page you did. Then allowing for a separate playback window so show an animated version of the file, while the main file remains unchanged.

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.)

This was the reason for my original plan, a simple extra gui pannel which would be minimalistic and not likely to effect much of anything else as well as being damn useful on it's own. But with the plugins it offers enough functionality to make animation _possible_ instead of a pipe dream.

Reconsider doing it my way.

Best regards, Martin Owens