Wild idea: MD2 and MD3 support.

[Argh]

I've been looking into the issues of having a RK format for Spring, and it appears that the MD2 format, which is widely supported by a lot of animation programs, is being used in a lot of GPL projects (Quake III engine on down have been GPL'd), as is the newer MD3. It appears that iD has been quite open to the idea of allowing people to make use of their model formats, there is quite a lot of documentation available, and there are exporters for MD3 for Blender, among other things.

What does everybody think about this? Since we're supposedly going towards a cleaned-up rendering pipeline, with Child's project, maybe this is a good time to talk about what we actually would like to see in an animated model format.

MD3 is pretty amazing, and might be a good match, because it supports shaders as part of the model format, but isn't a "live IK" format- like MD2, the animations are still static. This factor, imo, means it could be a good match.

I don't personally think we want anything more advanced than MD3, because of the CPU overhead associated with IK solvers, but MD3 might produce really excellent results for games, without making coder's lives difficult- the code for translating / viewing / loading / running MD3, and the animations, is widely available, and wouldn't require doing anything uber-complicated to Spring, other than having some way to have BOS support to tell the game engine when to run animations. I think that could be surprisingly simple to put into the Spring Engine, given that MD2 and MD3 consist entirely of "canned" animations:

Code: Select all

AimWeapon1()
{
  if (moving)
  {
     GET MD2SCRIPT (WALKAIM);
     aiming = TRUE;
  } else
  {
     GET MD2SCRIPT (STANDAIM);
     aiming = TRUE;
     notmoving = TRUE;
     DoStuffThatCausesCharacterToStayPut;
  }
  Sleep HoweverLongAnimationCycleIs;
  return(1);
}

Anyhow, for anybody who'd like to read up on MD3 and weigh the relative merits of this, I'd suggest looking at these projects:

http://ioquake3.org - current repository / main location where the Quake3 source, released under the GPL by iD, is being worked on. Probably could get a lot of questions about how to use MD3 in Spring answered there.

http://www.bpeers.com/software/q3ase/ This is a full-featured viewer for MD3 files, including some shader support. Newer shaders have been added to ioquake, but it's still a good, solid tool for people to look at stuff.

Personally, I think that if we used these GPL-compliant model formats, and a very lightweight renderer, we could have just about what we want here, without the giant overhead associated with picking up an engine.

[Neddie]

I think you may be on to something... at this point, MD2 looks pretty nasty in FPS most of the time, but with the scale of units rendered in RTS and the effort we put in, it should be able to meet all of the needs for Spring, and MD3 will offer us more.

[KDR_11k]

I don't like this idea. Both formats only support vertex animation, if you're going to add a new format at least make it use skeletal anim so we don't have to segment the meshes to turn pieces for aiming and stuff, 'sides, vertex animation makes filesize (and thus memory footprints) grow linearly with the vertex count and the frame count, a 2-3k poly model with some long animations can be 20 megabytes just for the mesh data. From what I read VA is CPU-heavier than SKA too, AFAIK console games avoid VA because console CPUs tend to choke on it.

Segmented meshes and all that with md3 is a pain in the ass, I'd rather have a clean skeletal format with animations split into separate files and no stupid tag triangles.

Also I don't know WTF you're smoking to talk about IK solvers when deciding on a model format, IK is an engine feature, not a format feature. While including IK constraints might be useful for some purposes (e.g. ragdolls) it does not mandate runtime IK. MD5 can do skeletal anim and Doom 3 does IK but that doesn't mean you have to use IK for anything MD5-related

[Argh]

Um, there's no reason you couldn't move segments using BOS, the old-fashioned way, if they were treated as Pieces by the game engine.

I'm not talking about doing something like a tank with this- what we already have is perfect for that. Instead, I'm talking about doing stuff like DoW, where units just turn themselves toward the target, execute an animation, then fire.

As for CPU loads... well, that's worth arguing about, I suppose. However, the flip side is that whatever format is used must be supported by at least a few packages- MD2 / MD3 are the only ones I know of that are supported by multiple suites, not just Max / Maya / Blender.

[KDR_11k]

Segments, yes but with skeletal animation you don't NEED segments! Maintaining segments in MD3 is a serious pain in the ass.

[Argh]

What format is available, that's GPL, meets your criteria, and is widely supported by multiple animation suites?

COLLADA's the closest match, but having read a bit, I don't like it, it's massive overkill for the scales and needs of Spring, and it has a lot of rough edges, frankly, and is not something that we could transition guys used to working with Wings and S3O to very easily, in my opinion.

[Pxtl]

Really, vertex and skeletal are two seperate features that aren't incompatible. You could have vertex animations on a per-part basis (so an MD2 model is a single part, and you set it's frame the same as setting position or rotation), and skeletal animations are a full model (where each bone is a part, which you move about). Obviously, you couldn't use them in the same unit, but they'd both be useful for Spring.

MD2s would be useful for "animation from outside of COB script", while skeletals would work better within the context of COB script.

[jcnossen]

Argh: You're talking as if there is nothing between full inverse kinematics and simple MD2/MD3 vertex animation.
Vertex animation would be impossible to control easily with cob, as there are no pieces, whereas COB would fit a skeletal animation format perfectly.

There are a LOT of good skeletal animation formats, think Cal3d, Ogre, Quake 4/doom3 models...

Bottom line is, the current unit model code is still very unflexible. 3DO/S3O is hardcoded with if's everywhere, and class names don't make sense. I tried to abstract it like a year back, but could never get all the piece transformations right in a way where everything worked.
Abstraction is what needs to happen, after that adding new stuff isnt so hard.

[KDR_11k]

What format is available, that's GPL, meets your criteria, and is widely supported by multiple animation suites?

MD5?

[Argh]

This is the last statement concerning the export script for Blender. Moreover, the format is proprietary, not GPL.

Moreover, that leaves us with only Blender as the application for working with this stuff, unless we want to pirate Maya or Max. Not ideal, but I suppose it won't kill anybody to learn how to use Blender.

[EDIT] I have read the latest in the thread, and it looks like this does still work, for the latest builds of Blender.

Abstraction is what needs to happen, after that adding new stuff isnt so hard.

Wouldn't the fastest way be to get all of this stuff out of the main source, by resorting to a lot separate #includes, at least at first? Yes, I am aware that that "leaves it in", in a literal sense, and it's inelegant, but then it should be possible to start reworking that code as a seperate animal, and maybe find the places it can all be streamlined. Having stared at bits of that code before, I think that most of the problem, honestly, is that it's just so scary-ugly, mixed in with the rest of what's going on. I thought about doing that, with all of the hardcoded FX stuff, too, but I've been busy with stuff that's more immediately pressing.

I'll look into this, when I get done with what I'm doing now, which should be fairly soon (i.e., hopefully sometime this week). Maybe I can do the grunt work, and get this going somewhere. Worst that happens is that I waste my time...

[jcnossen]

I don't think code licenses apply to formats, as long as you don't use the original md5 header file.
It's not illegal to learn from the header to write your own code to read the file.

[Argh]

Ok, then the main problem's cleaning up the code enough that it can be done, then? I'll get back to this when I'm done with what I'm doing right now.

[KDR_11k]

'sides, MD5 is ASCII, not a whole lot to do wrong there.

I don't know what you want to #include there, really.

[jcnossen]

#include <Awesomeness.h>

[AF]

imo if we use a new animation system we should not add in a tonne of cruft to backport it to cob/bos, it should either stand on its own two feet or sit alongside lua, because any bos/cob speed argument goes out the window as soon as you start doing things like bos<->lua etc.

As for discussion, there's no reason why you lot couldn't do all this in lua and showcase it as an argument for putting it in the main engine. Actions speak louder than words, and working code almost always trumps a forum post.

[imbaczek]

lua md5 renderer? sounds too insane to not try :> need a brave soul with a little too much time on their hands, though.

[KDR_11k]

Per-unit lua doesn't seem like a bad idea to me, COB is mostly used for animations anyway and a simple "Spring.PlayAnimation" call will take care of most of that.

[eriatarka]

lua md5 renderer? sounds too insane to not try :> need a brave soul with a little too much time on their hands, though.

I thought he didn't mean the renderer, but the animation code...?

As I have stated in another thread, I think replacing COB with Lua (for a new model format) is very possible, speedwise.

[AF]

The main reason lua based animation would be slow is because cob<->lua is slow. Implementing an animation API entirely in C++ and pure lua could make the whole thing faster than cob by taking advantage of the superior lua compilers.

[smoth]

Argh, makes another thread where all I can say to him is: ERGH.

Why do you push for some odd format? Why not help fix upspring's animation format. IK is expensive, and vertex and IK are not the same thing. I am not reading the thread because I don't want to read through the wall off text. Sorry if someone else has already said it, I get tired of repeating it.