I'm happy to see the growing interest in this project. For licenses, I have reread the BSD license again and I must say it is growing on me. Just to be clear though, is the only real difference between the (current) BSD and MIT licenses the "don't use our names to endorse your product" clause in BSD? Because I've seen MIT with a similar clause appended...Are there any other real differences that I may not have realized? My curiosity is piqued since multiple people here have expressed a preference for BSD over MIT, so I want to be sure I understand why.

As far as names go, it may be worth explaining that the name REACT was proposed as referring to a character responding dynamically to a situation, and mentioning that I've been revising the acronym a bit on recommendations -- the current iteration was Robust Extensible Animation Control Technology. (The Control is in there referring to control theory, as I realized the "Animated Character Technology" didn't in any way suggest that anything dynamic was actually going on.) I must say l0calh05t, I do like how Toolkit fits in well describing this library (as there still is some assembly required, but it'll give you what you need to do a lot), so I'd then further adapt the name to be Robust Extensible Animation Control Toolkit. CAST is good too -- I like the stage reference. What do other folks think?

As for hosting, I'm starting to lean towards google code projects now. It sounds much easier to deal with and faster to get moving than source forge, and I kinda like the idea of encouraging competition by trying out the new competitor. The only thing I'm potentially concerned about is the lack of support for some advanced features, such as being able to do server-side build steps on commit...It would be nice to automate some unit testing and to auto-generate and host documentation and the like. It's possible that google may yet unveil this support sometime soon though, and the project could always switch hosts later on if deemed appropriate.

Before I move on for the day, here's a simple diagram I whipped up that maps out some of the (high-level) design I had in mind so far for the library:


The crux of the dynamic animation library (the one being proposed here) is the kernel, which manages the internal state of information and acts as a central intermediary between all other bodies of code that seek to manipulate or request that information.

I realized that much like how the library does not need to be dependent on any particular physics engine, it likewise does not have to be dependent on any particular character animation library -- thus enter the bridges. Implementations following the design pattern of the same name, these would be bodies of code that connect two distinct libraries, responsible for directing information between them, so that the two libraries need not depend on each other. With the exception of the controller bindings (although, if there do perchance happen to already exist a few standards for defining controllers, as may be the case amongst researchers, it would be quite cool to have a bridge for each...) these bridges would be add-on libraries that are not part of the core but that are still essential for functionality (like, say, drivers in an operating system). I expect that they would still be part of the repository code base, but would be built as separate libraries to be optionally linked in as needed. Some application would then depend on the core (consisting of the kernel and core drivers) and any other necessary non-conflicting drivers, and whatever other libraries those drivers connect to.

Note that we could just as easily have a bridge to PAL as to any specific physics library, so we wouldn't require folks to depend on PAL if they don't like it (and prefer to go straight with Havok, for example).

Thoughts?

I really like the Bridge idea. I think that would work perfectly, as long as the Kernel is completely independent of any particular bridge implementation. What exactly are the Controller Bindings for? I'm not familiar with what that exactly does.

That's my intention -- that the core library (the piece including the kernel) would only define interfaces for the bridges, and make no further assumptions about them other than that they implement the bridge interface. At the moment the plan is for three types of bridges, which I'm sure would require separate interface designs (though there may be some elements they share in common) -- those to skeletal character animation libraries, to physics engines, and to controllers.

About the Controller Bindings, these basically serve as the link between the kernel and the controllers. The controllers are bodies of code that drive dynamic animation, and really could take any of a number of conceivable forms, though I had been assuming that they would quite frequently be scripts -- hence the use of the term "bindings." I realize now that it's probably better to just follow the more generic term and file this as just the third type of bridge, since you might want your controllers to be compiled code or in any previously conceived format.

The design of this interface is definitely still in the research phase, a lot of which being wading through research papers to see how other people do things and to try to assess what sort of standards are already out there. I'd definitely appreciate any help in this area (thanks already for those links, l0calh05t!). I know DANCE has their own format, which seem to be arbitrary hand-coded controllers or simple descriptions of static poses that straight-forward PD controllers (feedback loops that take derivatives into account) are used to drive between, with python scripts to compose the various aspects of the simulation together (models, collision data, actuators, etc). What NaturalMotion uses for Euphoria is a mystery to me, though I understand one thing they do is run many generations of genetic algorithms to "grow" effective animations.

One thing that the DANCE people write about is requiring that the controllers have full read access to the current model state, and that they implement an interface for assessing if pre-conditions are met, and for determining whether the controller is succeeding or failing (so that a higher-level controller, if you wish to arrange a controller hierarchy of some sort, could assess whether to switch behaviors). My first thought is that they be simple agents that in the abstract just reflect on the current status of the model at large (and any other data they are privy to) and issue commands to the kernel that call to apply torques at joints as desired.

Thoughts?

For character animations to take off there have to be a few key elements:

Standard skeletons, standard file formats, compatible mesh formats (preferably those used by easy to use free tools) .

An easy to use skeletal animation editor (including nifty interfaces like the graphical cyclic pattern maker, and joint action limiters)

A place people can publish their (now standard) animations so that they can be reused by others (ditto for the scripting for multisequence actions where associated animations are tied together for real uses).



Like so many others I have a need for hundreds of animated actions, but with all the work that goes into creating one I cant have enough time to do just that (ontop of the rest of the simulation engine/AI system which is the primary project). As far as Ive seen the 'industry' hasnt figured out any standards or organized a way to open up the creation process to amateurs.

There are thousands of common gestures and actions to be created and having the creation process made easier and within the reach of the multitude will do for animation what paint and photoshop did for 2D texture production.
Having them publish openly allows incremental development where one persons efforts are incrementally improved by someone else.






A seperate issue: There is some interface between the physics engine and the terrain mechanism (since the surfaces are required to be defined for the contacts/collisiones and friction factors, etc... That information requires standard terrain information components for the objects to interact with.

I think you guys are basically arguing for the same thing really -- to have an internally C++ library with a C API trimming. I've seen this done before, as in ODE for example, and I definitely see why a C API would be a lot easier for other languages to bind to than a C++ API would be. However, I don't see the harm in exposing the C++ API as well as the C API, so that C++ programmers would have the option of using the C++ API directly. So I think the way to go is to essentially go ahead and write it as a C++ library (making extensive use of the modern engineering practices we know and love like the various design patterns), but continually maintain a C wrapper API that other languages can more easily bind to. In the end I don't expect the kernel to be very big -- it's mainly just a housing for the various bridges and the central pump for data flow -- so maintaining this C wrapper won't be so daunting a challenge as, say, wrapping up a massive scene graph library.

While C#/Mono support hasn't explicitly been set as a priority, I certainly wouldn't want to stand in the way of improving the accessibility of this library. To that end, I will definitely add the instating of a C API wrapper (not replacing but in addition to the directly exposed C++ interface) and the option of building custom containers instead of using the STL to the list of priorities for this project.

In response to your other points CoreyWhite, Horde3D and Bullet would indeed be great libraries to bridge to. Once the framework is in place and published, I hope the community at large will assist in developing all the bridges we could ever need. (: They'll be standardized and maintained within the same repository as the core. I see inverse kinematics as a control problem, so it's beyond the scope of the kernel, but possibly not the core at large. It might be most appropriate to handle problems like IK in a higher level control library that the kernel would bridge to, and since the exact scope of the control aspect of this project hasn't been fully fleshed out, I can't really say how it would best fit in for now -- certainly getting the infrastructure in place and working is the more immediate priority...But I'm sure it will find its place, and it's likely that it will be in the same repository.

Going backwards to wodinoneeye, you bring up some interesting points about standards. As far as I know, this is entirely new territory, and much work has yet to be done to arrive at such standards. Perhaps here is a good place -- what ideas do people have? My first thought, for standardizing an animation format, is to have keyframe animation, where each keyframe is a list of torques/forces applied to joints. This would probably best be coupled with some sort of judgement thresholds that deem whether we're remaining successful or if something has gone awry and we should abort.

With regard to physics and terrain, it seems to be common for physics engines to each have their own standard way of creating collision meshes for heightmaps (and other irregular 3d geometry). I'm confident that this problem is already taken care of and does not need to fall within the scope of this library.

Finally, I've some good news -- I may be able to get funded for this project! I work as a programmer in the Serious Games industry, which means I write training and simulation software comprised of 3D real-time environments (basically non-entertainment video games). I've been discussing this project with my employer, who definitely sees the use of ragdolls in our applications, and who's been gaining interest in being able to have characters dynamically perform some agile maneuvers. So, they might potentially be willing to let me work on this project on company time, essentially funding its development. It's not at that point yet, as they would prefer that I write something tailored specifically to the engine we use, Delta3D (which internally uses CAL3D and ODE). However, my intention is to whip this up and then massage it into a more general purpose library, and then have it publicly published.

[Edited by - Danathus on July 17, 2008 3:49:29 PM]