I have some "fuzzy" ideas about the improvement and extensibility of ogre's animation system. I thought i could implement them my self but i dont completelty understand how it works.
The idea is to animate paremeters of Materials like colour, textures, particles pos, particles params etc and almost any thing in a generic way. A track of an animated object from a 3d app can be used else where like animating any scene node etc.
First the ogre::AnimationTrack should be a generic and an ogre::PRSAnimationTrack should be derived and used for animation of nodes.
And there should be some AnimationTracks and relevant KeyFrame classes like...
Ogre::Vector2AnimationTrack
Ogre::Vector3AnimationTrack
Ogre::Vector4AnimationTrack
and relevant KeyFrame classes.
These can be used for animating paramenters for example colours, gui stuff, and many other things. a animationtrack.track.xml file will contain animation tracks exported from 3d software like 3dsmax. Each animation track will have its own name.
So eg in material script we can write
ambient UseTrack("ogrehead/ambient_track")
diffuse UseTrack("ogrehead/diffuse_track")
With some kind of list/blending controller it will be possible to have an offset or avg. to them.
There should be some discreet controllers to like
Ogre::BooleanAnimationTrack, where each keyframe will have a bool value. Can output both boolean and fuzzy value.
And like
Ogre::TextureAnimationTrack, where each keyframe will refer to the index of some texture.
And a EnumAnimationTrack or IntegerAnimationTrack, which can be used to animate params like which require enums or integers as input.
The advantage is that we will have a common interface, common representation and reusability of animation data etc etc? Also the file.skeleton.xml file structure will also change as tracks will be seperted. These ideas will may also promote the streaming of animation.
Actually these ideas were inspired by working with animation systems like 3dsmax and maya. From this post im not expecting replies like "Why not do it your self....." but rather some positive views.
About a generic animation system
- ahmedali
- Gnome
- Posts: 302
- Joined: Fri Feb 20, 2004 8:52 pm
- Location: Lahore, Pakistan
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
I don't agree that this should be integrated into material scripts etc (as it's entirely possible to drive this from outside), but I have thought about a more generic animation engine in some occasions as well.
The Controller system already provides some building blocks for binding animators to certain properties, I think that's a good start. (look at the Sinbad's lights in some demos
More advanced than for pulsating though, you'd want some controllers that 'follow' arbitrary user defined tracks for other properties than position. This way making it possible to bind the AnimationTracks to other properties than Node location/rotation.
Next step would be making it data driven through scripts (seperate scripts from the current material/shader ones, mind you
The Controller system already provides some building blocks for binding animators to certain properties, I think that's a good start. (look at the Sinbad's lights in some demos
More advanced than for pulsating though, you'd want some controllers that 'follow' arbitrary user defined tracks for other properties than position. This way making it possible to bind the AnimationTracks to other properties than Node location/rotation.
Next step would be making it data driven through scripts (seperate scripts from the current material/shader ones, mind you
-
- Gnoblar
- Posts: 3
- Joined: Wed Dec 31, 2003 4:52 pm
Just FYI: in the course of implementing the Maya (scene) exporter we knocked up a little AnimationManager for Scene animations, too - data driven of course, values of animation tracks can virtually be bound to any property in a scene (also custom ones).
@:wumpus: thanks for the hint to the controller system, I almost missed that I'll try to incorporate them as soon as I get time to read up on them...
@:wumpus: thanks for the hint to the controller system, I almost missed that I'll try to incorporate them as soon as I get time to read up on them...
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Yes, controllers give you the ability to loosely couple the driving of parameters from external sources, one of which might be a keyframe source. I too have looked at the animation systems of modellers (XSI in my case) and thought how groovy it is that everything and anything can be animated, but there is one fundamental difference - they don't have to run in real time. XSI takes an approach where there are tracks for every parameter, and they are plugged in through a simple global name - great for flexibility, but when it comes to runtime it's something of a nightmare - even for skeletal animation you have 9 tracks per bone, each of which is separately interpolated.
I think a pragmatic approach of special-casing important animation types (like skeletal animation and morph animation), and driving other animation through controllers is likely the best approach. A completely generic animation system for all purposes sounds like a good idea, but in practice would be something of a drag for the subsystems it's actually most often used for.
I think a pragmatic approach of special-casing important animation types (like skeletal animation and morph animation), and driving other animation through controllers is likely the best approach. A completely generic animation system for all purposes sounds like a good idea, but in practice would be something of a drag for the subsystems it's actually most often used for.
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1