Vertex Animations

[very_bad_soldier]

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

Just out of curiosity: why not use VisualStudio and avoid that mingw toolchain?

[SpliFF]

Betherith asked me the same thing so I'll save myself some typing and give the same answer:

That would presumably involve buying VS right? I really don't consider it worth the trouble of stealing and I was under the impression the free versions don't build much. I was also under the impression it has a long string of bugs and incompatibilities which make porting cross-platform software difficult.

The blame for the problem I'm having is with Microsoft since it's a long-standing bug/limitation that they have simply never bothered to fix. Linux builds don't have this issue because the linux execv()/spawn() doesn't have a 32k limit on arguments. It doesn't really seem right to run to MS for a solution when they are the source of the problem.

Anyway I have other options.

[very_bad_soldier]

I thought the Express-Edition does all what is needed for "normal" usage but cant tell for sure.

[Beherith]

A very important setback of VS builds is that they don't sync with main spring.

[Pxtl]

Realistically, is ASSIMP going to happen? Or is this like the whole SM3 thing all over again?

[SpliFF]

There's no reason it won't happen. I have it 99.5% working and it's only waiting on windows testing. There's one minor bug I know of and probably some stuff I've missed but really, it works.

It was basically ready 6 months ago. What happened was I travelled and took on a large commercial web project. I haven't had much time until last week to finish it off. I spent most of this week fighting with weird bugs in the compile system which have since been identified.

Right now I'm building the TDM compiler suite from source code to build a fixed collect2.exe. If it all goes to plan (and it probably won't) I'll be able to compile Spring on Windows within the hour.

Once I've done my testing I'll push all the new stuff to github and it can be tested by the community. When it's stable enough to join the main repo I'm sure it'll make it's way into the official repo. At that point though it won't be my decision anymore so beyond that I can't say.

I assure you though it isn't vaporware. It just needed love.

[aegis]

I'm building the TDM compiler suite from source code to build a fixed collect2.exe

http://springrts.com/phpbb/viewtopic.ph ... 49#p449949

[Argh]

Well, that is promising.

As for the rest...
1. Most RTS engines use Havok. They don't have various physics in various places in the engine. A falling rock and a falling bomb all use the same core routines.

2. Most are using models using IK for ragdoll and LODs to keep the poly budget within pretty tight parameters. Same stuff as FPS games, they just different poly budget concerns and make more use of strict timers. In a RTS, we don't have to worry as much about interrupting an animation to do something else.

3. Other than having to be reliant on OpenGL, how big of a factor is cross-platform, either in terms of stability or speed? In any case, if it's a bit slower, that's just unavoidable.

4. Other than shoving the economy to Lua-land (which should be done) and shoving CEGs to Lua-land (which is almost entirely possible, if I release the current build of P.O.P.S.), and coding a generic weapon system mainly run via Lua (which having a genuine physics engine would be useful for)... IDK, how much is left that doesn't need to be? Aircraft flight, maybe? Some UnitDef stuff that could be handled via LuaRules? I might be willing to tackle the Lua side of dealing with minor stuff, if there was interest.

Moreover, how much of that general gamecode is a performance drag ATM? My understanding has always been that it wasn't much of an issue.

5. None of these things limits the number of actors. That's mainly an issue of vertex limits and GPU/CPU limits. Using characters built with single-skin techniques makes LODs a lot more practical, amongst other things, and my guess is that they'll actually prove a lot more efficient than BOS in terms of CPU cost.

Moreover, if this stuff doesn't make BOS and S30 obsolete, who cares? The OTA mods can just ignore it all. Nobody said we have to keep the future within OTA parameters, in terms of giant armies.

6. Forgot the time issue...

A. I've built rigged humans, modeling to finished, in 6 hours. Really, once you know how to rig, it's not that bad. Rigid-body things (like robots) are really easy- no harder than rigging up S3O.

B. If people release shaders Open Source, artists can worry about art, and shader people can worry about shaders. Meh... one of the projects that I haven't gotten done is to show a demo of a lot of different shader techniques(i.e., picking the one that does exactly what you need, no more). I'll try to find the time to put where my mouth is on that, since I need to streamline the uber-shader I built for P.U.R.E. as part of the optimization process anyhow.

[AF]

BOS is already obsoleted by lua, and the shaders have to be opensource else it invokes a new GPL war thread

[Argh]

Well, this would require something that was either an extension of the current Lua or was a new set of callouts / callins (we'd have to be able to query the current animation state, amongst other things), but yeah, I totally agree with both points.

[AF]

No, we wouldnt need it, we already have it, infact we had it back when you left, and some mods use no BOS or TDF at all

[Argh]

You're just trolling, lol

Nobody has said anything about using anything but Lua to talk to the engine about animation states and to deal with control logic. It's obviously the best solution.

[smoth]

I don't understand what you are trying to say with your last post, please more details but not a page.

[KaiserJ]

which rts games use havok?

i'm quite familiar with it, and tbh i would have thought it far too cpu expensive for a rts game with lots of little dudes running about

[AF]

You're just trolling, lol

Nobody has said anything about using anything but Lua to talk to the engine about animation states and to deal with control logic. It's obviously the best solution.

No Im not and thats backseat moderation. You yourself were the one who raised the lua flag

[Argh]

which rts games use havok?

Here's a current list, includes both DoWII and SC II. This isn't anything like a complete list, either. The engine I'm playing around with uses Havok, for example.

I don't understand what you are trying to say with your last post, please more details but not a page.

Simply put, engine should deal with loading up models and handle animation states and interpolation tasks.

Lua-land should deal with control logic, i.e., what animation are we playing, when and why.

It's debateable, but I think that shaders could be encapsulated in a format where either they relied on a fixed set of available engine options to perform rendering tasks (i.e., uniforms for camera matrices, lighting, textures, the usual crap) or were free to use logic to get and send whatever they wanted. IOW, not a whole lot different from jK's shader template system for unitrendering, which I still think is a very good idea.

For most regular uses, the former would be sufficient- regular materials aren't going to want to use more than 3 textures, will want the world light, access to the reflection cube and shadowmap, etc. etc. But the option needs to be there for all the special stuff people would naturally want to do.

[smoth]

true it would be nice if the engine could handle normal skeletal anims and interpolation but that isn't what we have right now. The devs know it, I know it, you know it everyone knows it. What is lacking is someone who will do the work to add such a thing to the engine with scriptcallable support etc.

So unless I am missing something I just don't get the point.

[Beherith]

Realistically, is ASSIMP going to happen? Or is this like the whole SM3 thing all over again?

Shut up. Spliff just stated that he is very close to release.

SM3 was a flawed concept in my opinion, and I have hashed this out many times before.

SSMF is far superior to sm3.

Edit: removed some nasty stuff.

[Argh]

Glad I didn't get to read the nasty stuff, it might have burned my delicate ears

I've tested the ASSIMP viewer. If I wasn't convinced before, I am now. I haven't tested with a vertex animation or a SMD containing animations yet, but it worked just fine dealing with SMD mesh data.

[AF]

Starcraft 2 and Dawn of War II dont have to deal with the unit counts and numbers of unit types we have in our engine