Vertex Animations

[Argh]

Just thought I'd drop by briefly and bother people again.

Practically everything I've seen outside of this place uses variants of the Quake animation formats, or at the least the central concepts / conceits.

It's a big deal, in terms of new projects. People outside here know all about rigging and character development for rigged models, but they know nothing about programming in either of our two languages for that purpose.

It probably stops a lot of people in their tracks, as well as limiting the artists here from building better stuff.

Moreover, models built that way are a hell of a lot more efficient, in terms of numbers of display lists and vertex counts. And formats like the Half-Life 2 format (SMD) support LOD, multi-materials, etc., etc., and make SM3 look like a joke, in terms of artist support and shader efficiency (use only the shader you need for this bit, so forth and so on).

So, is it possible to get a discussion going about this again, maybe get people thinking about it seriously? I will be disappearing again now, so feel free to rant, froth and flame me if you'd like. But this issue, along with map / level-design, are two big things that the engine really needs, seen from an outside perspective. That, and having a full-fledged physics engine (say, borrow OGRE's or Blender's, maybe) so that building things like vehicle sims and other character movement isn't an extremely painful reinvent-a-wheel kind of issue.

This has all been said before, but I'm saying it again, because if there's anything I've learned from doing other stuff, it's that the rest of the world isn't doing it like Spring, and it's an obstacle for anybody seriously looking for an engine to work with. The engine could do a lot more, if it wasn't so harshly limited in these areas, which basically cut the engine off from doing a lot of things, both creatively and from a game-design perspective.

Anyhow, I'll be back in another month-ish, if possible.

<poof>

[AF]

This belongs in feature requests not Development.

Also bare in mind that just because the format supports it doesnt mean that all these features will magically arrive the moment the engine supports loading of geometry from them. These things take time and effort.

I would look into the work done on ASSIMP, but if you'd stayed around here and looked, you'd see that plans for a rather hefty set of structural evolutionary changes are being made for the rendering ( and not a 'here here we've designed it, now lets build it in a 24 hour dash', but a 'this is where we're headed and we've already made a few steps and till take a while').

In the meantime, there really is nothing in the way of implementing a lot of these things yourself in lua, and I advise you do so where possible using a clean coded, well thought out design, because those are the kinds of implementations that get handed about the community and reimplemented in the engine.

[Peet]

OGRE's physics engine

You are literally the most proficient person I know at discussing things about which you have absolutely no knowledge.

[smoth]

>:\ does it really matter? I mean are you going to fix pure?

[Argh]

My apologies, I didn't know most OGRE builds were using a third-party physics engine like ODE, peet. I've never built an OGRE project, so I presumed that it was built in, or was a default option.

Anyhow, point is that there are solutions that don't involve reinventing the wheel.

Smoth:

I intended to, and I got a lot of stuff done, but to be perfectly frank, I reached a stage where I couldn't look at it any more without being annoyed with the gulf between what I wanted and what I could get the engine to do without running at a crawl. I should probably just get what I have stable, call it 1.3, and declare the project dead. It'd require a high-end gaming box to be playable though.

I was thinking about building something new, using the stuff I built for P.U.R.E., that wouldn't rely on the engine's shadowmap support or lighting system, and a better game design that doesn't send me down the road to Content Hell quite so much. IDK whether I want to use Spring or not, tbh- it's only real advantage is familiarity.

Hence why I'm asking if it's possible for us to have the ability to use content made and animated using the tools the rest of the world uses. It's another Spring game when I get done being fairly bored by being a mod king again or I need to try and find developers and do something else.

[PicassoCT]

Wow a chicken and egg discussion, we have a bad animation system, therefore less people contribute, because its difficult because of bad animation system, which we wont fix, because so limited people contribute, its not worth fixing at alls, because the people who propably would use it, wont fix it, because our animation system is bad.

First to break vicious circle looses puplic support.

[Argh]

It's not just the animation system. It's how artists interact with content and how developers build support for content.

In all the modern game engines, artists pick a Material, which is a reference to a shader and some bitmaps, and assign it to a Mesh. It's a system that means that if I write a shader for Game A, then (presuming my code is Open Source) you can just drop it into Game B, select it as part of building a Material, and voila, you can use whatever it is.

From an engine perspective, it means the engine doesn't have to worry about shader support directly. It just has to worry about sending certain types of data and running the animation system so that the display lists do what they're supposed to do.

And, from the animation end... instead of giant scripts, you get scripts that are like:

IF dead == 1 AND runningAnimation != blah THEN doAnimation(blah).

Animation support frequently allows variants randomly chosen, cyclical stuff, etc., and bone addressing, i.e., "override these bones, all other bones do whatever they're doing, if they aren't in the default state". So, if you want a character to shoot a gun during a walk cycle, you can call an animation for "shooting gun during walk cycle" that overrides the upper body bones, but doesn't override the legs and pelvis.

It's a giant difference from this engine, where even doing something like that is frequently a complex pain in the ass, and requires a lot of coding experience.

[jK]

In all the modern game engines, artists pick a Material, which is a reference to a shader and some bitmaps, and assign it to a Mesh. It's a system that means that if I write a shader for Game A, then (presuming my code is Open Source) you can just drop it into Game B, select it as part of building a Material, and voila, you can use whatever it is.

It isn't that easy. Commercial games don't use proprietary model formats for nothing. There aren't many easy to use and flexible model formats available and those which aren't very popular. But ASSIMP is a big step into that direction - it allows you to use very complex (XML-based) formats in your app etc.

[Argh]

OK, I'll buy that- I know that a lot of commercial engines have some pretty big restrictions on what you're able to do.

Looking at what ASSIMP supports, it looks perfect for import.

I guess my question is that after import, the engine needs to be able to handle, "this callout requests the animation states of this bone set, applied to this mesh", right?

So, would I be correct in presuming that we'd still need to settle on a standard format, to reduce import hell and make the engine not have to deal with the idiosyncrasies of every possible format ASSIMP would support?

There's also the issue of coordinate issues, etc.- one of the modeling hells I've seen while wandering is that there are a lot of editing suites which claim to support format X, but game engine Y has issues because they use a different coordinate system and there isn't a parameter Z to tell the engine how to fix stuff at runtime, so artists are screwed if they don't use the exact import / export configuration or software used by the engine developers.

There aren't many easy to use and flexible model formats available

I agree.

I'd have to vote for exactly two: NIF or SMD. SMD is my preference by a huge margin. It is well-supported by a lot of applications, and it's flexible enough that it won't be worthless any time soon. I used to think that MD5 would be the future, simply because iD gave away all the code, but I was wrong.

SMD has ended up being far more popular. The support for it, for people using free / Open Source / cheap tools is far better.

[AF]

We're aware of issues like coordinate systems and matrices, Ive used ASSIMP myself and I can say that there really isnt anything that we dont already know, we even have an ASSIMP fork of spring somewhere, though what happened to that branch I have no idea.

But even with ASSIMP, and the information it provides, this does not mean we instantly gain inverse kinematics. We've heard this speech from you before Argh, and its always the same, we dont need you to manage it for us and try to push forward a step by step reasoning to help us. We know how, thats not the issue.

We could go and implement this all now very hurriedly for the next release. It would be buggy, it would result in problems, it would be unsatisfactory, and it would lead to complaint threads from yourself.

I would suggest you instead learn C++ and help contribute patches towards advancing the restructuring effort so that a fast efficient performant implementation of what you want is possible. Right now you have wasted more of your and our time in threads like this telling us what we already know, and vaguely looking at what has been posted.

From our perspective, you have just waltzed in from a hiatus at a different game engine, told us what we already know and what we should be doing. Do us the respect of at least getting up to speed with recent advances before you announce you are back and tell us all what we should do

[smoth]

And, from the animation end... instead of giant scripts, you get scripts that are like:

IF dead == 1 AND runningAnimation != blah THEN doAnimation(blah).

I have this now in bos, when I go over to lua I will have an even better version..

[Argh]

Yeah, I know it can be done and stuff. I use BOS to check Lua and then do other crap in BOS- it's like one of those horrible hentai tentacle things in terms of complexity.

I've seen systems where you just have attack1, attack2, attack3 and so forth, and you just specify an animation sequence positions time and blend, and that's all- nubs who know how to animate can just make stuff and write something very un-codelike and voila, it just works. Granted, it "just works" provided the character meets some very specific requirements- all those systems are for engines where most characters are humanoid.

Oh, and hi Smoth, glad to see you're alive and well and stuff.

I just fixed the lighting-system-makes-characters-float-away bug in P.U.R.E. and updated it to the current engine build.

Who knows, maybe I'll get around to releasing it or something. Other than the ATi issues and a niggling "lua stack" error related to some cyclic junk that I need to hunt down, that was the worst of the bugs.

[smoth]

I am not well, I hate 90% of the people here and only post because my project will be ignored by the devs if I don't bitch loudly.

[Argh]

Well, sorry you're not well.

[AF]

Aside from the obvious misinterpretation Smoth chose to ignore, one can easily manage to write pure lua animation code where you could make such a comparison.

Quite simply I'm astounded that nobody has built a modular OO framework to help encapsulate animations already, and that everyone has instead chosen to reimplement the same animations over and over again every time one or two things needs tweaking.

[hoijui]

i think it would be good if you started your own mod, AF.

[AF]

I did, I wasn't impressed by what I had created, it didnt meet my personal standards, so I buried it in embarassment. It was almost as much a failure as my attempt at a catface RTS, only I never managed to get beyond a half finished catface model for that particular project.

Prior to that I had an OTA mod back in 1999 that was even worse, that was before I could program or model properly, so Im not surprised by the epic fail. I buried that after I realised that a retextured resized peewee constructor was not a suitable builder for a 3rd faction.

Most successful enterprises in modding Ive made have been as a part of other games, e.g. the XTA fusion reactor concepts and models which spawned the whole shiny thing in the center of fusions craze...

[SpliFF]

I revived the Assimp branch last week. The only thing holding it up is my current inability to build and debug Spring under windows.

I appreciate what Argh is saying but it's still crap. You can't compare an engine optimised for RTS to one optimised for FPS. Nor can you fairly compare commercial titles to free ones. The goals are completely different.

* Most RTS don't require physics
* Most RTS don't require sophisticated character animation
* Most RTS are optimised for high-end Windows and don't run on linux.
* Most RTS aren't engines, they're optimised for a specific game with some "modding" that's generally not as flexible as a new game really needs.
* Most RTS that have these things require extreme resources and severely limit unit counts.
* Most commercial games that have all these things still fail to gain significant traction. The 2 most popular RTS games in the world are still Warcraft 3 and Starcraft 1 with the most recent of the pair still more than 6 years old. So despite your assertion that adding sophisticated effects to the engine will drive up adoption it isn't backed up by real data.

Now just say we had all these things, where's the content supposed to come from? It literally takes days or weeks to put together a simple animated and diffuse rendered model now but just how much longer would it take to build complex animation structures and shaders on top of that? Commercial games have whole teams of people working 40 hours a week for several years to build the content for their games. What chance do 1 or 2 modellers with little experience, limited tools and limited time have to properly showcase any of these features?

You can't compare Spring to Ogre. Ogre is more of a platform that still requires your game to be coded in C++. You could put an RTS on top of it but then you'd lose on optimisation and ease of use because the engine would still still be too general purpose.

You can't even compare Spring to successful open-source. Most of the best open-source content, including the linux kernel, is the way it is due to heavy commercial backing. This is essentially why the most polished parts of OSS are business/productivity and server software.

There's only ever been 2 companies that invested heavily in OSS games. Loki, who funded the development of SDL, and TransGaming/Cedega who fund the wine project. If Spring had funding like that then sure, you might see the kind of features you're talking about. Perhaps that's something for Argh to think about when P.U.R.E makes him rich *snort*.

[smoth]

Aside from the obvious misinterpretation Smoth chose to ignore

I am too tired, jaded and bitter to correct argh any more. you can do it all you want but I am ignoring things because I see no point in it. It is better to worry about what effects you. What effects me was that I supported him by buy pure which doesn't even work and was disappointed by it. The animation stuff I could give two diddle fucks about because it isn't getting done and therefore doesn't effect me.

[AF]

The main obstacles to driving adoption are a lack of viable frontend and a coherent ingame UI, but mostly the lack of workable frontend. By which I dont mean a lobby with a singleplayer tab. I mean a proper frontpage with buttons etc, the kind zwzsg has been experimenting with and applying to games, all packaged nicely in an installer with a site that explains how.