CEGUI (Crazy Eddie's GUI) Forums

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

[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

EDIT: AnimationSet instead of AnimationContainer.

Bump

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.

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

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.

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

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.

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.

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.

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.

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?

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.


The same thing subscribed to events

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

CE.

Just abusing the forum as a pastebin



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


LookNFeel files


Hope I haven't forgotten anything

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.