Generic animation support for CEGUI::Window

Discussion regarding the development of CEGUI itself - as opposed to questions about CEGUI usage that should be in the help forums.

Moderators: CEGUI MVP, CEGUI Team

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Generic animation support for CEGUI::Window

Postby Kulik » Mon Aug 02, 2010 13:12

I think it would be really nice to have some sort of animation capabilities in CEGUI::Window. Even though it's mostly just eye candy, in specific cases it aids usability by hinting the user where to look. Plus CEGUI is meant for games and multimedia applications and eye candy is tolerated in that kind of stuff.

I propose creating a class CEGUI::AnimationSet (or something). This class would contain CEGUI::Animation elements. CEGUI::Animation could just support keyframe based animation of properties or we could do it generically so that key frame animation is only one specialization class of CEGUI::Animation (not decided yet). Each animation would support looping, wrapping, or just "run once" and could be started, stopped, paused and unpaused at any time. Something like stepAnimations will be called every injected time pulse by CEGUI::Window and it would call CEGUI::Animation::step for each contained animation.

Then we could simply inherit CEGUI::Window from CEGUI::AnimationContainer and gain free animations.

Furthermore I would like to add support for that to .looknfeel files so that you could define animations including keyframes and then bind them to specific events via their string names. This way you could include skin specific animations to your .looknfeel file.

Example usage 1:
You click the close button of FrameWindow. This is bound to a method that will start the "Close" animation and bind handleCloseWindow() to "EventAnimationEnded" of the "Close" animation. The close animation could simply fade alpha or even shrink the FrameWindow by altering size or any combination of both. And when the animation ends it will fire EventAnimationEnded and the method that will really close/destroy the window gets called. Same thing for opening new frame windows.

Example usage 2:
The hovering state of buttons, checkboxes, etc could fade in and out instead of just switching instantly.

Example usage 3:
The FrameWindow rollup could be gradual.

Example usage 4:
With the new fancy rotation propery of every CEGUI::Window, Windows that don't have mouse over them could rotate sideways to take less space and when you place mouse over them, they would rotate back to you. Adding something like Zoom property could provide even more senseless eye-candy :D

[Example usage 5:
Switching tabs could quickly slide the tabs left and right until the desired one is there - this will probably be tricky...

This isn't priority number one for me, but I could work on it in my spare time once I get the layout containers working and upstream if there are enough people that would like it. I am asking for ideas (any specific use case you would like to work and it wouldn't with this implementation?) and endorsement 8)

EDIT: AnimationSet instead of AnimationContainer.
Last edited by Kulik on Mon Aug 02, 2010 14:55, edited 1 time in total.

MarkR
Quite a regular
Quite a regular
Posts: 64
Joined: Thu Jul 15, 2010 06:55

Re: Generic animation support for CEGUI::Window

Postby MarkR » Mon Aug 02, 2010 13:24

Bump :hammer:

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: Generic animation support for CEGUI::Window

Postby Jamarr » Mon Aug 02, 2010 17:57

You did not really elaborate on why CEGUI::Window should inherit from CEGUI::Animation (or whatever you want to call it). Simply making the Animation API accessible through the Window API is not a sufficient reason, imho. It would only add clutter to an already cluttered interface. To put it in OOP terms, a window is not an animation; an animation acts upon a window. I think it would be cleaner to have an external animation interface with which animations can be added, and with which windows could be assigned.

Also, there is an existing third-party animation interface for CEGUI called UIAE, though I have never looked at it.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Generic animation support for CEGUI::Window

Postby Kulik » Mon Aug 02, 2010 17:59

@Jamarr: You probably haven't read the topic carefully.

CEGUI::Window : public PropertySet, EventSet, AnimationSet

Window would be a set of animations.

EDIT: Damn, I was searching for this and missed UIAE, will look into it...
EDIT2: I suck at fast reading - I think having external API isn't good enough, animations are requested from developers. Plus having the capability to integrate them with looknfeel would be great IMO. The overhead would really be minimal. AnimationSet would contain one std container containing the animations, if there would be any, there would be minimal overhead. I agree about API clutter but what can you do, look at the size of CEGUI::Window now...
Last edited by Kulik on Mon Aug 02, 2010 22:57, edited 1 time in total.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Generic animation support for CEGUI::Window

Postby CrazyEddie » Mon Aug 02, 2010 18:20

Ok.

Firstly, I like the idea of an integrated animation system. I'd intended such a thing from the outset back in 2003, but, like so many other features, it did not materialise yet ;) But I think there does need to be discussion about the best way to pull that off (so it's good that this thread it here!).

The main thing to be taken from UIAE, I think, is that it's properties based, and any integrated system should follow that approach also - although there will likely be other scenarios that do not fit into that model, so those could be worked out as things progress along in the design.

Ok, for the Window inheritance thing, that's definitely not the right way IMO. Animation and related things are totally visual in nature, and the window/widget base classes should not contain anything related to that as far as possible - this is how come we split out the rendering parts into the WindowRenderer classes to keep the visual and logical aspects separate. (NB: I also hate that the Window class is already massive, but the above is the 'right' reason for not adding another base class there.)

I agree about integration with the looknfeel system.

I'll have to think about this some more, so keep posting any ideas and such here, and I'll add to it whenever something either catches my eye, or I come up with some ideas ;)

CE.

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Generic animation support for CEGUI::Window

Postby Kulik » Mon Aug 02, 2010 22:30

Adding animations to window renderer means that Windows without WindowRenderer can't be animated, the question is if there are some use cases where animating these could be usefull. However I agree that they are strictly visual.

We could even do this by implementing a new singleton that would manage all animations - AnimationManager?. This would be most powerfull, because you could animate virtually everything. Animations could be added by WindowRenderer from the looknfeel, no more Window API clutter, whilst you would still be able to animate anything (inherited from PropertySet of course) even in Windows that don't have WindowRenderer set. I still don't know how to cleanly destroy animations on Window's destruction but WindowRenderer could do that by keeping track of it's added animations and custom animations are users responsibility anyway...

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: Generic animation support for CEGUI::Window

Postby Jamarr » Mon Aug 02, 2010 22:38

Right. Skimming often leads to incorrect assumptions ^_^. So, re-reading some of this it sounds like you want CEGUI::Window to maintain a set of animations that are associated with an event (ex: window-close). So whenever the event is triggered, if an associated animation exists, the window would play the animation. I suppose the user would specify whether the event should fire pre- or post-animation. In the case of close-window, the event would generally fire post-animation; but in the case of mouse-click or -hover it may be preferable to fire pre-animation. This sounds reasonable.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Generic animation support for CEGUI::Window

Postby CrazyEddie » Tue Aug 03, 2010 18:42

A new AnimationManager is certainly a possibility. I like things with clean separation and extensibility - to allow the user to do things that I/we never thought of, so the more decoupled the whole thing is the better :)

CE.

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: Generic animation support for CEGUI::Window

Postby Jamarr » Wed Aug 04, 2010 17:36

CrazyEddie wrote:A new AnimationManager is certainly a possibility. I like things with clean separation and extensibility - to allow the user to do things that I/we never thought of, so the more decoupled the whole thing is the better :)


Right. I think the key idea here is that a window /needs/ to know about it's properties and events to function, where as the window does /not need/ to know about associated animations to function. And this is precisely why animations should be separate from the Window interface; one should always avoid coupling when one can.

I will say that having Window inherit from PropertySet and EventSet can be misleading. Depending on how you define a window (definitions are always subjective), imo: a window /is not/ a PropertySet or an EventSet - it merely /has/ properties and events. In this definition, it is incorrectly using inheritance (is-a) to model composition (has-a) relationships. This lends to the confusion because we then say, well, a Window "has" a set of animations so we should also inherit from an AnimationSet.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Generic animation support for CEGUI::Window

Postby CrazyEddie » Thu Aug 05, 2010 08:55

Yeah, the relationship between Window and the PropertySet and EventSet bases is not technically "is-a", though I'm not somebody who subscribes strictly to rules in design (unless I wrote the rules myself for some reason). I believe there are scenarios where for any number of reasons adhering to those idioms rigidly does more harm than good. But anyway, that, I believe was not your point... I do agree that the fact I did decide to have those collection wrappers as base classes can/will/does encourage other people to maybe get the wrong impression ;)

CE.

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Generic animation support for CEGUI::Window

Postby Kulik » Fri Aug 06, 2010 13:06

Ok, so AnimationManager would store animations and would be updated when time pulse is injected. It would step all animations.

I think often you want to animate more things at once with one animation, so..

What about Animation having duration, position and replay method (play once, loop, very useful would probably be something that would be increasing animation position right to the end and then decreasing it again to the beginning - usefull for vista-like progress bar for example...).

And inside Animations, there could be Affectors. Each propety would have it's own affector. Affectors would have keyframes and would do simple interpolation between 2 neighbour keyframes.

I also thought that it would be interesting to create a concept of AnimationInstance. This way we could store animations just once even when we had 100 windows. I don't know if it's worth it though. The instance would just store the position of animation, everything else would be taken from the Animation itself.

The last thing that I need before this works is something like d_dataType in CEGUI::Property. Then I could just add Interpolators for each datatype and keyframe's could just be strings...

Any ideas?

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Generic animation support for CEGUI::Window

Postby Kulik » Fri Aug 06, 2010 13:43

OK, how I think animations should be declared in looknfeel :)

Autostarted animation that never stops, starts after window is created and loops to infinity. With autoStart="false" user would have to start it because it isn't bound to any events.

Code: Select all

<WidgetLook name="Look/Widget">
    ...
        <AnimationDefinition name="TestingAnimation" duration="2" repeat="loop" autoStart="true">
           <Affector interpolator="colour" property="NormalTextColour">
               <KeyFrame position="0" value="FF000000" />
               <KeyFrame position="1" value="FFFF0000" />
               <KeyFrame position="2" value="FF000000" />
           </Affector>
        </AnimationDefinition>
</WidgetLook>


The same thing subscribed to events

Code: Select all

<WidgetLook name="Look/Widget">
    ...
        <AnimationDefinition name="TestingAnimation" duration="2" repeat="loop" autoStart="false">
           <Subscribe event="Clicked" action="Start" /> --> just starts the animation
           <Subscribe event="Clicked" action="Pause" /> --> toggles pause
           ... Stop, Rewind, maybe more?

           <Affector interpolator="colour" property="NormalTextColour">
               <KeyFrame position="0" value="FF000000" />
               <KeyFrame position="1" value="FFFF0000" />
               <KeyFrame position="2" value="FF000000" />
           </Affector>
        </AnimationDefinition>
</WidgetLook>

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Generic animation support for CEGUI::Window

Postby CrazyEddie » Sat Aug 07, 2010 13:31

Just to put a note here for other users to say that I'm not igoring this thread, but rather that it's being discussed on IRC :P

CE.

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Generic animation support for CEGUI::Window

Postby Kulik » Tue Aug 10, 2010 20:50

Just abusing the forum as a pastebin :-)

Code: Select all

<AnimationDefinition name="TestingAnimation" duration="2.0" replayMethod="loop" autoStart="true">
... name is a string and is required and must be unique (falagard will prefix this to make sure)
... duration is required, it's in seconds and is a float, it should always be greater than 0.0f!
... replayMethod is optional (defaults to loop), possible values - "once", "loop", "bounce"
... autoStart is optional, can be "true" or "false", defaults to "false"

... AnimationDefinition should contain at least one Affector, otherwise it would be useless
    <Affector applicationMethod="absolute" property="NormalTextColour" interpolator="colour">
    ... application method is optional, possible values - "absolute", "relative", defaults to "absolute"
    ... property is required
    ... interpolator is required and is a string value (can be anything, exception is thrown when interpolator is not found), in future interpolator may not be required and could default to Property::d_dataType

        <KeyFrame position="0" value="FF000000" />
        ... position is a float, is required, should be greater or equal to 0.0, I am not sure whether to enfore it to be lower or equal to duration...
        ... value is a string, is required, can be anything virtually, even a blank string, but it has to be specified
        <KeyFrame position="1" value="FFFF0000" progression="linear" />
        ... progression is optional, it's a string, possible values "linear", "quadratic accelerating", "quadratic decelerating", "discrete", if progression is specified for the first key frame, a warning that it will be ignored could be helpful
        <KeyFrame position="2" value="FF000000" />
    </Affector>

    ... auto subscriptions are optional
    <Subscription event="MouseEntersArea" action="Start" />
    ... when auto subscription is specified, both event and action are required, both are strings and map 1:1 to defineAutoSubscription method in CEGUI::Animation class
    ... possible action values "Start", "Stop", "Pause", "Unpause", "TogglePause". more may be added in future
</AnimationDefinition>


Animations.xml - AnimationManager::getSingleton().loadAnimationsFromXML(file);

Code: Select all

<Animations>
   <AnimationDefinition>
   ... same as above
   </AnimationDefinition>
</Animations>


LookNFeel files

Code: Select all

<WidgetLook ...>
... the stuff that's already there :-P

    <AnimationDefinition>
    ... same as above, only name is prefixed "WidgetLook/TaharezLook/Button/" + name of animation
    ... BUT I think we should warn the user if autoStart is false and no auto subscriptions are defined, the animation would unlikely be used then
    </AnimationDefinition>
</WidgetLook>


Hope I haven't forgotten anything :D

User avatar
emarcotte
Quite a regular
Quite a regular
Posts: 55
Joined: Fri Dec 26, 2008 14:30
Contact:

Re: Generic animation support for CEGUI::Window

Postby emarcotte » Wed Aug 11, 2010 10:40

Could you include links to the patch you listed on IRC? I was going to try it out on another box to see if my app had the same issues with textures being all weird after animation. I suspect (though I'm still not sure, need to try some other stuff) that it has to do with how I am bootstrapping OGRE with an SDL window.


Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: MSN [Bot] and 1 guest