Easier way to do Animations?

edited July 2012 in Help request
I'm currently considering getting seriously into making some stuff with Orx and fell in love with the feature list on first sight, but the way the Animation system works currently put me off a little since it seems awfully tedious.

I need to tell it what Animations there are, then I have to define pretty much all transitions, including the looping, and put them in a linked list, then have to tell each individual animation what kind of Keys its made up of and then have to create a new image object for each of those keys telling it what position of the original texture to look for the frame. That's easily over 200 lines of code (or, well, data) for just six frames of animations making up Idling and Walking. I'm dreading to think of the kind of work it'd be to implement bigger spritesheets or even multiple bigger spritesheets. I'd probably spend entire weekends just writing hundreds of lines full of Animation inis.

Now, I'm not complaining, I was really just wondering if this is the only way to do Animations or if this is just the "I want full control of everything" way to do it and if there's maybe a "Just give me some Animations, I don't care too much about their inner workings" way.

It just feels so backwards that in an engine that's so trimmed towards fast and easy prototyping animations are such boring, long and tedious work.

Comments

  • edited July 2012
    Hi DoctorBeard and welcome here!

    You're totally right, defining the animations is definitely the biggest weakness of orx as we speak. When the system was designed an editor was supposed to be created that would handle all this for the user. Unfortunately that never happened yet, and one has to write that huge quantity of info to create animations (and it used to be worse!).

    I've been trying to refactor all that in the process of adding support for skeletal animation but this isn't done yet and doesn't have any ETA.

    Right now, defining the whole animation graph in config (ie. including all the possible transitions) will make it very easy to use in code as you do not need to need to write pull-code for chaining animations.
    The classic example being a character sitting and needing to run, if you define the sit->stand up, stand up->start run and start run->run transitions in config, all you have to do in code is call orxObject_SetTargetAnim("run").
    No matter where he was all the transitions will be executed in time, the way they were defined in config.

    That being said you don't need to define the whole graph and can then skip the links. You'll then have to chain the animations yourself in code.

    As for the animations themselves, you need to define every frame and every frame has to be an orxGRAPHIC so I'm not sure how you modify the config aspect of it in this case.

    However you don't have to write everything by hand! You can actually write code to fill all the config info at runtime for you. I think this approach has been discussed a couple of times in those forum, here for example: https://forum.orx-project.org/discussion/1467#Comment_1476

    More generally, all the config info can be modified/created at runtime which works pretty well when it comes to parts that can easily be automated (like animations).

    If you have any propositions on how to make the whole system better/easier to use, don't hesitate, when one is too familiar with the system it's not always easy to stand back to come with better ways of doing things.
  • edited July 2012
    PS: Forgot to point to the new animation module thread: https://forum.orx-project.org/discussion/3886
  • edited July 2012
    That just about covers everything, thanks :)

    I'll either just sit tight and wait or if I do decide to pick up Orx for what I'm planning will just write a quick and dirty animation editor for myself (or generate them at runtime, like you described)

    Just wanted to make doubly sure this is currently the only way animations work. I can't even count how many times I tried to simplify a process for myself only to find out there already is a simple way to do it.
  • edited July 2012
    DoctorBeard wrote:
    That just about covers everything, thanks :)

    My pleasure! :)
    I'll either just sit tight and wait or if I do decide to pick up Orx for what I'm planning will just write a quick and dirty animation editor for myself (or generate them at runtime, like you described)

    Let us know if you encounter any other issue or if you have any other questions, of course!
    Just wanted to make doubly sure this is currently the only way animations work. I can't even count how many times I tried to simplify a process for myself only to find out there already is a simple way to do it.

    That's the best approach I think. :) There are many many things that have a more simple way of doing in orx that in "traditional" engines (including shaders, offscreen rendering/compositing, etc...), unfortunately the animation system config part isn't one of them. :/

    Did you have a look at Scroll/ScrollEd, btw?
    It even simplifies more things than to a vanilla orx use does.
    There are a few threads on the forum as well as some tutorials being written by acksys: http://orx-project.org/wiki/en/orx/tutorials/community/acksys
  • edited July 2013
    I also agree that orx makes many things easier, but animations are still cumbersome. Now, I love Orx's simple inheritance implementation, but has anyone explored adding a simple parameter polymorphism (EX: templates in C++, or generics in Java). I think for animations this were be perfect because we could create a new animation for each object. This would allow us to create animation quickly. For example I could create a solider using the template with just:
    [SoldierGraphic]
    SpriteSheet         = soldier_full.png
    Texture             = soldier.png
    Pivot               = (15.0, 31.0, 0.0)
    [SoldierCharacter]
    Graphic             = SoldierGraphic
    AnimationSet        = AnimSet$SoldierGraphic  ;The Animation Object would be passed SoliderGraphic at creation to instantiate a AnimSet based on SoldierGraphic.
    Scale               = 1.0
    

    Then the templated code would be something like...
    [AnimSet$TemplatedParameter]
    AnimationList = IdleRight$TemplatedParameter#WalkRight$TemplatedParameter
    LinkList = IdleRightLoop$TemplatedParamter#WalkRightLoop$TemplateParameter
    [IdleRightLoop$TemplatedParameter]
    Source      = IdleRight$TemplatedParameter
    Destination = IdleRight$TemplatedParameter
    [WalkRightLoop]
    Source      = WalkRight$TemplatedParameter
    Destination = WalkRight$TemplatedParameter
    [IdleRight$TemplatedParamaeter]
    ; Our idle animation is only one frame here, that lasts for 0.05s
    KeyData1      = AnimRight1$TemplatedParamaeter
    KeyDuration1  = 0.1
    [WalkRight]
    ; We have 6 frames in our walk animation
    DefaultKeyDuration  = 0.1; <= This defines the duration for all our frames unless locally specified differently
    KeyData1            = AnimRight1$TemplatedParameter
    KeyData2            = AnimRight2$TemplatedParameter
    KeyData3            = AnimRight3$TemplatedParameter
    KeyData4            = AnimRight4$TemplatedParameter
    [AnimRight1$TemplatedParameter]
    Texture     = TemplatedParameter.SpriteSheet
    TextureSize = (32, 48, 0)
    TextureCorner = (0, 96, 0)
    [AnimRight2$TemplatedParameter]
    Texture     = TemplatedParameter.SpriteSheet
    TextureSize = (32, 48, 0)
    TextureCorner = (32, 96, 0)
    [AnimRight3$TemplatedParameter]
    Texture     = TemplatedParameter.SpriteSheet
    TextureSize = (32, 48, 0)
    TextureCorner = (64, 96, 0)
    [AnimRight4$TemplatedParameter]
    Texture     = TemplatedParameter.SpriteSheet
    TextureSize = (32, 48, 0)
    TextureCorner = (96, 96, 0)
    

    The TemplatedParameter.SpriteSheet is really SoldierGraphic.SpriteSheet--just passed down. Now if we wanted to create another animation we simply do:
    [BeholderGraphic]
    SpriteSheet         = Beholder_full.png
    Texture             = Beholder.png
    Pivot               = (15.0, 31.0, 0.0)
    [BeholderCharacter]
    Graphic             = BeholderGraphic
    AnimationSet        = AnimSet$BeholderGraphic  ;The Animation Object would be passed BeholderGraphic at creation to instantiate a AnimSet based on BeholderGraphic.
    Scale               = 1.0
    

    And so forth for each monster. Naturally the AnimSet could be extended to include walking in all directions as well. This way we can build a simple database of animation templates in the .ini.

    The basic difference between the inheritance and parameteric polymorphism(PP) is that PP would create a new object per instance while the simple inheritance would be just one object. Naturally I'd keep the same restrictions as the .ini's simple inheritance to make things simple.

    I know we can do something similar in code/Scroll, but I think it would be cleaner if it was supported in the .ini Thoughts? I can't be the first person to think of this...

    ~Paul
  • edited July 2013
    PauloftheWest wrote:
    I also agree that orx makes many things easier, but animations are still cumbersome. Now, I love Orx's simple inheritance implementation, but has anyone explored adding a simple parameter polymorphism (EX: templates in C++, or generics in Java). I think for animations this were be perfect because we could create a new animation for each object. This would allow us to create animation quickly.

    Hi PauloftheWest,

    You're entirely right about the cumbersome animation/graph declaration in config.
    Historically orx was supposed to come with an editor that would have hidden all those verbose and ugly sections for the user. Unfortunately the editor was never made.

    You're actually not the first one to propose templates to solve that particular issue, I'm sure it has been discussed at least once on those forums (though my search-fu is too weak to find it) and it has been discussed a couple of other times via different means of communications.

    I completely agree with the fact that this is an elegant feature, however I'm not sure if it would apply to other common cases/scenarios than animation/graph.

    I have a task (that you can find on orx's issue page on bitbucket) about adding support for vectorial animations (as well as adding the concept of channels to that same system).
    Part of this task is also to provide a much more concise way of describing animations via config (while still allowing for a more verbose option in case the user needs fine-tuning). There's a branch that was created over 2 years ago (ouch!) that you can see on the repository.

    I should really to focus on this in short-term future as I think it's currently one of the weakest, if not the weakest, part of orx.

    If you have any idea about how to make the description of animations/links less verbose and not such a pain in the ass without resorting to new features (actually it still look pretty verbose with templates: it allows a user to easily duplicate a graph for different characters however the graph template itself still looks annoying to write), please let me know.

    That being said, the template feature per se might be interesting, I just need to find out better use cases as this precise one might (hopefully) disappear in the future. :)
Sign In or Register to comment.