Sorry your browser is not supported!

Yet another "pro" feature makes its way to DarkBASIC Classic for the masses to use. This one is based off of DarkBASIC's memblock mesh example 3, and inspired by a game called SoulHunter. It allows you to interpolate the vertex data of a mesh between two other meshes, also known as shapekey animation or even bone animation (although technically there is no support for actual bones/armatures).

This is a relatively low level function, meaning you will not magically get full bone animation. Jiggle physics, ragdolls, inverse kinematics, and long animations are all things that you would have to implement yourself.

With that said, here is a simplistic example showing a morphing deformed sphere:

Nice sphere! Kinda looks like a beating heart. The principal seems pretty straight forward - interpolate the vertices between a source and a target.

Check out the DBC Challenge thread. One of the last entries has a 3D snake that turns and moves over a morphing matrix. It's turning shows the basics of how to rotate joints for bone type animation. The bones are determined by grouped vertices.

I am unable to run it (I only have a DBP compiler), but by looking at the code I think that there's a flaw in it. If you try to interpolate, say, a human object who rotates his arm up, your program won't obey the rule to keep the joints always at the same distance from one another. They will simply find the fastest way from point A to point B and deform the arm to achieve this.

This could be helpful for you, these are the 3 rotation matrices for global rotations:



That should enable you to calculate individual vertex rotations around every joint.

TheComet

Not necessarily. This method of animation is based on keys being morph targets. The keys would have to be predefined poses and vertex index would morph to vertex index not just to the closest vertex. Defining the poses would be the real work. You'd have to have predefined mesh poses (vertice layouts) for each key frame. You then interpolate between frames.

A more computationally heavy approach would be to rotate groups of vertices (bones) around pivots (joints) in real time. This is the "skeletal" animation we are familiar with in DB. However, it is more flexible as you only need a single mesh definition and a "skeleton" to represent the joints and vertex groups. That allows you to make any rotation/pose on the fly not relying on predefined poses. The costs of the rotation calculations might be offset by not having to change all of the vertices if the whole skeleton isn't moving whereas in the morph key animation, you're likely to have to adjust every vertex - unless you define vertex groups and can identify which ones morph between poses and leave the others alone.

@Latch-

Full bone animation is something that I would love to see in DBC. Bytegrove/zzz posted an actual bone animation example on YouTube when he was working on SoulHunter, but he said in the description that it was very limited and only really worked with simple shapes. That snake example you mentioned sounds kind of cool, but still it seems to have the same limitations.

Regarding the speed, the keyframes could be precalculated and cached, but that still wouldn't solve the problems of the 3D math involved and somehow interpreting DirectX's bone animation system. Yikes!

One thing I did plan on doing was making some kind of markup to define the order and timing of meshes so that one could play back vertex animations like the DarkBASIC animation commands, but that kind of went to the back burner when I stumbled apon a heap of responsibilities quite recently. Maybe you could do that, Latch! The goal was to have a short string that pretty much listed the mesh numbers in order and the timing in between, and then to have commands for play, loop, and precise timing control.

I've tinkered with bone animation several different times for DBC. One approach was to convert Direct X files to some kind of custom format I could run my own equations on. The animation format of a Direct X file for DBC animation is fine, but when you get into skeletal animation, I find it's all over the place. The original file format was designed to create a scene and sub-scenes within those. These are called Frames in the file and limbs as we've come to know them. The design was entire scenes of meshes could be transformed in time and thus animation. If you link a bunch of scenes together, you can effectively create an animated character.

Skeletal animation for Direct X was kinda "inserted" into this frame work where now you have a whole other series of Frames that represent bones, and weights and matrices. All of these are called Frames or encased in frames without meshes instead of being their own thing. This just gets cumbersome when trying to match bones to meshes - so I decided not to do that.

Then, I thought I'd just use the direct x parsing commands to strip what I needed from the Direct X file. I got it working, but never went further than parsing the file.

Next I started playing with Cal3D. It's a platform independent animation system. By this time, I kinda decided the direct x file wasn't the way to go. If I could get vertices and their groups into cal3d, it would be a matter of having that library update all of the verts and then write them into a memblock. So I've got his on the back burner still. I look at it every so often.

Recently, I've been looking into building a custom animation system. For 8 Hours 'til Dawn (the community FPS of yesteryear), I built an animation system to adjust the limb positions for sparky's, so collision could be detected for animated objects. I was thinking of taking that system, modifying it, and finding a way to assign vertex groups to bones. Where ever the model is coming from, Blender, Anim8or, where ever, I'd have to be able to manage the vertex groups for DBC and it's really boring and time consuming writing conversion/exporting routines from a modeling program. I might go the route of developing an animation program for DBC where you build a skeleton for a mesh and assign vertices to bones. That's more interesting to me. I dunno.

It's all very possible to do and run from a DLL with little over head. The main overhead coming from MAKE MESH FROM MEMBLOCK and CHANGE MESH calls in DBC.

Sorry for the long post, but I'm just typing as I'm thinking...

@Latch-

Yeah, you could write your own animation program, but I'm not sure many people would use it. I was simply suggesting a way to play back shapekey animations. I think I'll make that my own project and just see what I come up with.