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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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/ja... _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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.

Hi Martin and everyone!

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:

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

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.

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