ArticulatEd Exhumation

I’ve always found the available tools for hobbyist game developers to be rather rudimentary, and usually full of gaps. A couple years ago, just before ragdolls were absolutely everywhere, I began work on an idea I’d had for a while to make an editor for articulated rigid body systems, specifically targeting character rigs. I had tried other free editors out there, but they all seemed quite cumbersome, and none had any of the more advanced features I wanted.

My first prototype was a simple program made with SDL, OpenGL, and ODE, written quickly and messily just to see if the idea had any merit. The interface design and implementation would have taken too much time in SDL, as well as its C API contributing heavily to the ugliness of the code, so I decided to start fresh.

The new version uses one of my favorite software libraries, JUCE, instead of SDL, leading to a much more rapidly developed and nice looking GUI. Additionally, JUCE’s fairly nice C++ object model lead to a much cleaner source base and more easily extensible designs. A quick video:

ArticulatEd’s interface is inspired in equal parts by Pixologic’s ZBrush and the FOSS Wings3D. Indeed, it is meant to complement those two miraculous modeling programs as a counterpart in the toolchain, serving both as a physical rig (or ragdoll) creator for meshes, and as a physical animation tool (eventually). The basic idea comes from my perceived need for a straightforward tool for constructing physical representations for the graphical meshes in a game or simulation project. Creating chains of connected rigid bodies should be as simple as possible, as should manipulating the created systems into different poses. By importing a modeled mesh, it should be easy to connect the mesh to deform to the underlying rigid body skeleton throughout its various poses. Joint constraints and motors to move through the poses should be easy to tweak, or even generated automatically by the implicit skeletal structure and the movements between the various animation poses.More to come.

Patchbaying .NET, part 2

It’s been some time, but I’ve been continuing with the visual patching system for .NET that I wrote about last time. After playing around with Cairo more and more, I decided that the component model offered by WinForms, while inferior in flexibility and aesthetics, gave enough of an upper hand in terms of developing controls that I would go ahead using that. Mono’s support for WinForms seems to be increasing all the time as well, so at least for now, I’ve decided to stick with it, and focus more on the gritty details of actually getting the system working well.

I still have a long way to go with the infrastructure, but I’ve gotten to the point now where I can realistically start developing targeted packages. My first focus is on getting an OpenGL framework going, for which I’ve found the Tao Framework quite handy. Unfortunately Tao still leaves a few things to be desired. For instance, OpenGL enumerations are simply wrapped as integers, which while true to the spirit of the underlying specification, is still a royal pain compared to the much more semantically strong .NET enumerations. Overall, though, Tao is proving itself to be a quick and easy way to get the functionality I need into this framework. It’s definitely nice to not have to deal with writing the interop code myself.

So far I’ve got a primitive mesh class written, which reads in WaveFront/Alias .OBJ formatted mesh data and renders it, currently using immediate mode. Obviously this is slow and silly, but it serves its purpose as a prototype. I foresee good things happening soon on this route.

Of course the development and brainstorming for all of this has led me to realize how much potential a program like this actually has. The concept of dataflow programming has somehow managed to escape the larger consciousness of the so-called computer science community. Certainly there are many people familiar with the concepts, and even a few working on such languages (many of the visual languages, in fact, lend themselves to dataflow naturally) but overall it seems to be much neglected, especially considering the prodigious benefits it offers. Things like parallelism, which are commonly viewed as difficult to handle in traditional languages, reduce to simple graph traversal problems in the dataflow paradigm. Long unconnected paths in a DAG of the dataflow system can be automatically parallelized by a computer. Sorting the operational flow by dependencies with a topological sorting gives the computer ample opportunity to optimize the problem. This stuff is cool, and it’s a shame it isn’t used more widely in the computing community. My hope is that, by bringing some of these concepts to the .NET world, where interop is so blindingly easy, many problems can be ameliorated. Exporting patches as C# source or even emitting assemblies directly are planned features.