Coder Social home page Coder Social logo

Comments (14)

aibosan avatar aibosan commented on August 20, 2024

You can use the picker tool for that - select the animation, select one or more keyframes to apply to, switch to the picker tool (F7) and click the path you want to take the data from. Picker's right click also gives you more detailed options, like copying timing off animations. The manual has more information on it. That's about the best way I found for it, seeing as selecting multiple objects really isn't a thing in the editor.

from anigen.

doctormo avatar doctormo commented on August 20, 2024

Ah I see. I will try this and let you know.

I was thinking that maybe Inkscape needs to have a plugin to compile multiple paths into d animations.

from anigen.

aibosan avatar aibosan commented on August 20, 2024

The problem with that would be that at that moment, you kinda need to add in a lot of new logic to Inkscape. When you move a path in Inkscape, for instance, the path data itself changes - not the element's transformation attribute. But if the path has a replace 'd' animation, this will not change, so the animated will no longer reflect the static state of the path (i.e. the static path will be moved, but the animated path will be in the same place). So you'd have to adjust animation alongside the path when you move it (so parsing values, or keeping the parsed values somewhere inside the editor, I don't know how you guys handle that stuff).
You'd also have to either disable path's node editing, or force the edits to the original path to apply to the first keyframe, which is supposedly what the path would display - but that's only if the animation actually starts at t=0. And this doesn't even mention you'd probably want to have the ability to edit keyTimes, begins, duration, and so on at this point, which means new UI.

Of course, if you don't really care about the user experience at all and just want something that compiles the paths into animation, that's probably hackable in Python in a day. I briefly thought of adding something similar as a function of a group, but decided it'd bloat the interface needlessly. On the other hand, I have a "batch" setting for creating animation states for animated group, which serves much the same purpose - select a group with a bunch of children with the same model (same number/general tree structure of elements) and you can turn them into states all at once instead of doing it individually. Then you can just create animated group which has each of those as a keyframe, can repeat states, and so on. The disadvantage is that due to the simplified way the animated groups are handled now, you won't be able to edit animations directly, or adjust the states without manually editing an object in the .

from anigen.

doctormo avatar doctormo commented on August 20, 2024

I'm not great at describing what I mean. So what I'm thinking is NOT to make inkscape do animations, so no timings, no renderings. What we need from inkscape is a simple way to do onion skins to construct my key frames. Then once I have those, I could use a python extension to output a compiled but NOT timed svg with animation elements. Then bring that into anigen or something similar to edit the keyframe timings, and see the animation actually animated.

It's a drawn out process, but the advantage is that you can use inkscape for doing editing where it's best and leave all timing and preview to animation tool.

from anigen.

aibosan avatar aibosan commented on August 20, 2024

This is actually just what I designed the "animated group" for.

In Inkscape, you simply create a group representing a single state of your animation - whatever complex object you want. You duplicate this group (and move it around if you so desire, since the initial transformation of the group doesn't factor into the state), and edit it to make the next state, and so on.

When you're done preparing the states, aniGen allows you to declare them as animation turn them into animated states (object -> object to animation state). States belong to groups which you can create instances of (object -> create animated group). The resulting object - animated group - which will behave much like any other animation. The key difference is that the value for each keyframe will be one of the states declared for that group.

There's a bit more to it, from being able to animate different attributes to being able to also add additional animations (like transformations) to the groups' children without messing things up. Plus, the whole thing still acts like a group, which you can treat as usual in Inkscape, moving it around, transforming it, and so on.

from anigen.

doctormo avatar doctormo commented on August 20, 2024

This is very interesting. So what I'm doing in inkscape is treating groups (layers in this case) as the control mechanism for making things visible and invisible for editing. See this screenshot of a work in progress:

bitmap

So what I have here in this design is a way to use layers (which are really groups) to quickly move through keyframes. I wonder, instead of an extension. Is there some way I could mark the groups, so that on import to anigen you could see these groups and configure them as the "animation groups"? I wonder what kind of attribute or meta data we would need to make this flow really well backwards and forwards.

from anigen.

aibosan avatar aibosan commented on August 20, 2024

To recap, this is the layer integration for creating animation groups:

  • (main layer) Group name
    • (sublayer) First state name
      • object to be made into state 1
    • (sublayer) Second state name
      • object to be made into state 2
    • (sublayer) Third state name
      • object to be made into state 3

Using the batch option, you can use the names in this tree to create the whole group of states at once, by selecting the main layer (Group name), and creating animation states from that. Keep in mind it requires each sublayer to only have one child; a group with the same element model as the other states.

The layers themselves don't automatically get turned into states when opening a document. Those are created at user's behest, and are saved in the document's for persistence. However, this could be integrated. Possibly as simple as adding some namespace attributes to the layers holding the states:

  • "anigen:type" = "animationState" (which is what identifies the states in
  • "anigen:group" = group name (possibly optional; I could, again, interpret the tree)

I actually like this idea. However, there's a question of what to do with any preexisting state data in .

If the data is kept, the new states will be added at the end of that list, which will quickly bloat with each open-save cycle of the data. This isn't good.

If the old data is removed, this could lead to several problems

  • Complete loss of data for some of the keyframes, if there are fewer states than there used to be.
  • Change of element model. If you, say, add a new path between the versions, the animation group won't be able to deal with this and would have to be instanced again.

It's important to note that existing animation groups don't get refreshed when file is loaded. This is to reduce calculation time, but also to avoid issues with loss of data in . Thus, the first point when an animated group is recalculated is when one of its keyframes' value is changed.

This leaves us two competing solutions:

  • Force refresh when new data is introduced in this manner. Potentially risky due to issues above, or
  • Disregard change of data until user manually forces refresh of the given animated group. Problematic when a user wants to keep the group up to date.

The only way I see of solving this would be to introduce additional flag of "keep in sync" for each instance of animation group.

Sorry for this wall of text. I just wanted to brainstorm this issue.

from anigen.

doctormo avatar doctormo commented on August 20, 2024

So adding new children into the groups has to be kept symmetrical to make it make sense to anigen.

So perhaps the better way to do it is to have the layer create have an option called "This is an onion" (or something less silly) and then each sub layer inside that is then treated like an onion layer with the above UI and the logic under the hood would do this:

  • The layer would have a mark saying inkscape:groupmode="ani-layer" or inkscape:layermode="onion"
  • Creating a layer would duplicate all items from the nearest sibling layer
  • Adding a new child element would add that child to all onion layer siblings
  • Deleting a child element would remove it from all onion layer siblings

What you'd end up with is a symmetric stack of layers. What would be needed from anigen is the ability to take those layers as animation groups allow the key timings and other animations to be changed and saved as animation elements. When updating, it has to trust that the when inkscape says it's symmetric, then it certainly is going to be.

Thoughts?

from anigen.

aibosan avatar aibosan commented on August 20, 2024

I just pushed my version, which works like this:

There's new setting option allowing you to load state data from whole document (not just defs). Data loaded from document take priority over defs, i.e., if the group was already created from defs, it's dropped completely, and remade from the document data.

There's a new toggle for instanced animated groups (in keyframe window), which makes them automatically rebuild when document is reloaded. Rebuilding completely bypasses the necessity to share the same element model (same general tree, e.g. "each state has two groups, first with two, the other with three paths"). Rebuilding carries over all other information, like values and timing.

There's also a rebuild button, which triggers the same thing.

The state data parsing from document has several possible tree structures it can interpret

  • Layer 1 -> Layer 2 -> (solitary) Group 1; Group name: Layer 1. State name: Layer 2. State data: Group 1
  • Layer 1 -> Group 1, Group 2; Group name: Layer 1. States created: Group 1, Group 2
  • Group 1 -> Group 2; Group name: Group 1. State created: Group 2.

Parsing is triggered by attribute anigen:type="animationState" anywhere in tree segment (be it one of the layers, or the leaf groups. For the last case, naturally, Group 1 cannot be "animationState", as it'd just go up one level.

So, onion layers should just have attribute anigen:type="animationState", and it should work. The only difference is that that all the edited elements in the last layer must be in a single group as well. Layer itself doesn't become a state. This allows the user to more the group around without having to worry about that changing position and values of the elements within. Basically, you can duplicate first state, move it to the side, and edit it, seeing both states side by side. Giving them the same transformation overlays them. Layers aren't handy for this, because inkscape makes them insensitive, so you can't easily move them.

(Crude) example file, with most options included: _state_tests.zip

from anigen.

aibosan avatar aibosan commented on August 20, 2024

Now that I think about it, if you make the lower layers something like inkscape:groupmode="onion", which Inkscape would recognize as layers, they'd still work as regular groups as far as aniGen is concerned, so you could get around the somewhat clumsy need of grouping all the elements in the layer.

But like I said, I find it quite useful to be able to to spread states around to inspect and change them in parallel, which Inkscape layers are just not good for. A solution for that would be having some kind of switch between "layered" and "tiled" modes; the tiled mode would distribute the layers so that there is no overlap. The problem is that if you edited an element to reach outside this boundary, it'd either lead to overlap, or pretty confusing reshuffling on the fly. But maybe it could just rearrange if you switched back and forth between the modes, or prompted the reshuffle, or there could be a setting for the size of individual tiles. But all of those solutions sound a bit cumbersome.

from anigen.

doctormo avatar doctormo commented on August 20, 2024

Hmm so it sounds like your workflow is done by moving groups into separate positions (as you mentioned above) and the onion skin method (which is what I would love to have) is the competing workflow. This may be intractable, but let's think it through.

We both want to use layers to group together a set of elements which would then be animated with the same key-timings. (but not necessarily the same /types/ of animation).

I want to edit them on top of each other, seeing the previous and next key frames are uneditable/selectable ghosts. Which layers work really well for since you can't move them around and can easily toggle their insensitivity and visibility with existing tools.

But you'd rather edit them side by side, with full visibility. Being able to move the groups around is an advantage and insensitivity and opacity are not relevant. This method is a bit like the pages, where each page can be moved around side by side.

I'll think of it as I take a bath and shave and maybe I'll be think up some way of doing both. In the mean time, what (if anything) would you like to see inkscape do for your workflow?

from anigen.

aibosan avatar aibosan commented on August 20, 2024

I use keystrokes a lot (you can see that in aniGen's design as well). Clicking UI with my mouse actually breaks my workflow. So, it's easier to (ctrl+d) a group, move it aside, (F2) to edit it, and so on, and when I'm done, opening the (ctrl+shift+x) and changing identifiers to name individual states.

To me, working with keystrokes is much easier and efficient than having to deal with an additional dialogue or window, just like entering groups is natural to do with a double click instead of a context menu option. Screen real-estate is always an issue, as I constantly have at least one, and usually two or three windows open, and other four in a minimized state on the tray, but I also need that information in my immediate view, so moving them to a different screen is not really an option.

As far as I'm concerned, having onion skinning would work, but there would need to be a support for global keystrokes while that mode is on. A quick few that I though of:

  • Ctrl + Shift + K to trigger the onion skinning (state making) mode while layer window is active.
  • Ctrl + Shift + J to switch between "stacked" and "paged" (tiled) modes.
  • 1 and 3 to switch between states. (Yes, this collides with pre-set zoom values, but maybe it could just be made content-sensitive.)
  • Something like Ctrl + 2 to duplicate state, or something that makes a bit more sense
  • Keystroke to delete state?

But seeing stuff side by side for quick comparison is important to me - when you're making ~40 different mouth visemes, for instance, it's great to see them spread out in a grid; just at a glance, you can tell you're missing some, or get some idea about adding one you didn't think of before. I think tiled
mode is important for anything that's is not just a single-loop animation. As an aside, the paged mode could actually just have the size being the page's viewbox by default.

Heck, I even actively use snapping bound to the ~ key, often for as short as a single node placement. Which reminds me, the way snapping turns back on when you undo is really annoying.

I also think your synchronization idea (elements being created in all states when created in one) is pretty great.

And opacity and even display can actually factor into the animation states - it's not just 'd' you can animate. For some more complex animations, you might want the option to hide certain parts of an object at certain keyframes (although the discrete nature of display makes it a bit clunky at best), or fade them out over time. Or animate color.

from anigen.

doctormo avatar doctormo commented on August 20, 2024

I see, so what you're most interested in is making sure there are key codes for the functions. Then after that making a tiled view.

I'll keep thinking about this problem, since I think it could be a good thing.

from anigen.

aibosan avatar aibosan commented on August 20, 2024

Essentially, yeah.

from anigen.

Related Issues (13)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.