Hmmm... They're asking a LOT of money for a project of not well-known people. "We're... It doesn't matters really. Point is, we want a quarter million dollars please."

Though their project looks like it could require such amount of money, by that I mean it may be too ambitious.

When it comes to middleware, it isn't the cost of THEM to develop it, what matters it the cost it would take for you or your project to implement the same functionality.

Could you implement the same thing, have it debugged, and have it available today, for less money?

Is it cheaper to use theirs --- which is available today at a known cost --- than it is for you to spend an unknown number of months re-inventing their wheel, debugging it, refining it, and supporting it, at an unknown cost?

As a member of the gamedev forums I thought I'd step in here and drop a line.

L. Spiro, you seem to just be describing some constraint solving method. It's not what I use but even so this would amount to a couple of line of codes, our character animation system is currently shy of 15000 lines of code.

Don't want to bash anyone or anything, it doesn't seem right to mislead people into thinking that what I've done here can be reduced to something so simple. It's the result of a really huge effort, lots of testing and tweaking and still it's a work in progress. I usually get things done very quickly, this has taken away inordinate amounts of my time.

Cheers,
Madoc

Elo again,

Pretty busy these days! I'll try to say something but going into any depth here would require a lot of time.

•How many rigid bodies can it currently support (on an average target user machine)?

Honestly we haven't really stress tested it, more than enough for our purposes. Probably in practice the most demanding thing is something that keeps the simulation fluid (no jittering and popping) and stable even when objects are put under impossible stress. Of course most of the time objects are resting and cost nothing.

What is still very demanding is cloth collision detection (you can see this on the cloak here). That's still going to need some clever optimisation.

•When it comes to importing the meshes to the physics system, are they converted to a low-poly version and fit with convex hulls?

Umm... To be honest this is something I'd rather not reveal while we're still so early in development with the game. We'd like to be able to use it first. I hope you understand.

•Any details you can share about the physics+animation combination would be cool.

Well, applying some forces to an articulated body is not a big deal but all you get is a body twitching awkwardly on the ground. Going from there to something that behaves like a character, that can maintain and recover balance, swing heavy weapons without falling over, get up from having fallen, run over rough terrain and do all sorts of other things is rather challenging. This needed a lot of procedural behaviours and basically a mountain of hacks, and the way it all interacts is the stuff of nightmares. A lot of the body is controlled almost purely procedurally and getting it to behave well in all circumstances has threatened to drive me insane. It's still a bit clumsy but I hope to improve it further, also with more predictive behaviours which have been somewhat neglected so far. I'm also looking to include more hand crafted solutions (i.e. for breaking or preventing a fall) which from the little I've picked up looks to be closer to how Euphoria works.

For some reason I still don't fully understand, I can't get traditional IK solvers to interact well with the system. I've tried this several times and just failed to produce anything that wasn't a bit twitchy (the people who made Euphoria are probably laughing at me right now). I have something that sort of does the job but it works in mysterious ways .