15 replies to this topic

[BobXIV]

Recently I saw an Indi game named "Sui Generis" (here is a video of it http://kotaku.com/5958364/we-might-be-looking-at-the-next-generation-ofindie-rpgs), it seems very interesting. There are two things that are particularly interesting: the physic interactions, the animation of the characters.

My question is related to the characters animation. I want to ask how you can make something like this, I mean the movements seems very "physic driven" to call it some way. I know that Euphoria (http://www.naturalmotion.com/products/euphoria/) is a very good dynamic motion synthesizer, surely with that you can make something similar but this studio doesn’t seem to be very big so they most probably don’t have access to that kind of technology. May be the animations are simple made with Maya, 3D Studio, etc and they have a ragdoll and nothing else... but the result is very good.

What do you thing guys?

[thedevsykes]

I'd say your probably right, and likely using some sort of physics API to generate a smoother after effect, especially when the skeleton is destroyed. I have to say thats a pretty cool looking game, but its probably done the same way most of the physic based 3D games are, just with a difference camera angle is all.

[kd7tck]

They might be using homebrew 3d scanning techniques. They would set up dozens of cameras in front of a blue screen and piece them together to form a 3d model. Otherwise they would have spent years tweaking animations to get that kind of organic movement. I have a feeling that much of the physics is pre calculated and recorded from cg actors into a series of animations.

Otherwise they are using one heck of a physics engine.

[L. Spiro]

I am not so sure this is too terribly advanced, as good as it does look.
It’s a combination of IK, FK, and physics.

Basic animations such as swinging the arms are likely FK, but not run in a standard sense. Unlike standard FK, they get to the desired position within the animation by determining what physical impulse to apply to each joint to go from the current position to the desired position. Limitations on the sizes of impulses allow the movements to get off track from what was originally modeled in Maya without immediately jumping back on track on the next update.
This means if an arm gets hit while swinging, gets pushed down a bit, it has to get back up to its target position over a series of frames, resulting in much more dynamic and fluid motions.

The feet are IK, and likely use something similar to Sumotori Dreams to keep the player balanced and upright.
This is a bit advanced but not new (since it was already done in Sumotori Dreams). Since the only task is to keep the player upright it could actually be simplified greatly so that any standard IK algorithm could be applied (again, with impulses to drive the joints to their target positions).


Once the animations are using nothing but impulses to get to their target frames, any standard physics engine could then take over to run it. There is nothing special about the physics engine etc.

Of course breaking the skeletons means breaking the relationships between the joints of it and then using standard physics to repel them off the ball-and-chain.


All-in-all, very practical to implement. Only the way the animation system runs needs to be modified, and that modification is trivial, since it is extremely easy to calculate what kind of impulse needs to be applied to get from one orientation to another over a fixed amount of time.


L. Spiro

[ATC]

All-in-all, very practical to implement. Only the way the animation system runs needs to be modified, and that modification is trivial, since it is extremely easy to calculate what kind of impulse needs to be applied to get from one orientation to another over a fixed amount of time.

Could you explain how you would go about making those calculations? I'm considering implementing this and some other things...

[L. Spiro]

Since we are only operating on joints and we assume them to be infinitely small (there is only one place on it we can apply any given force—this is unlike a box where applying a force to one of its corners almost always results in a different result from applying the same force to its center of mass) we don’t need to worry about where the impulse is applied in relation to the center of the joint. That simplifies things greatly.

Also we assume a fixed-interval time step here so that we can know the amount of time that will pass during the next update, because it is in that time that we want to reach the destination position.

So, for an infinitely small point with some mass, given an impulse over a given amount of time, the point will move by this much:
(F/M)*t
Where F is a force vector (and is 3D), t is time, and M is the mass of the object. Usually physics simulations store the inverse mass in order to avoid a division, and we are of course not accounting for friction or damping here (no need).

So you know where you are, you know where you want to be, you know your mass, and the amount of time you want it to take to get to the target.
D = 3D vector from starting point to end point.
D / t = How long it would take an object whose mass is 1 to get there in the given amount of time.
So if you have double the mass you need to apply double the force.
F = M * (D / t)


Of course you can then put a limit on F to make sure the arm (or whatever) doesn’t just jump to the target spot immediately, and this cap can be variable depending on how far away the target position is.
And all these equations should be done in joint-local space, otherwise you would have the hand trying to fly forward really fast when actually the rotation only involves the shoulder joint.
Convert the forces to world space afterwards.


L. Spiro

Edited by L. Spiro, 08 November 2012 - 07:52 AM.

[TheChubu]

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.

Edited by TheChubu, 18 November 2012 - 09:11 PM.

[ynm]

Does anyone know how to implement the physics collision at 00:59 in this clip:
https://www.youtube....h?v=PvZchE30StQ

It seems very accurate

[Cornstalks]

Does anyone know how to implement the physics collision at 00:59 in this clip:
https://www.youtube....h?v=PvZchE30StQ

Fixed that for you. That's just standard rigid body physics. Nothing special. Pretty much any rigid body physics engine will do, and even then there are more impressive things. Exactly how he auto-generated the collision mesh from the graphical mesh, I'm not sure, but there are various methods (assuming he generates a poly-reduced mesh; he could be using the full mesh, but for high-poly models that's computationally expensive).

@L. Spiro: how costly (CPU-wise) are such animation/physics combinations?

[L. Spiro]

I can really only estimate, but the extra overhead shouldn’t be too much, especially since you can avoid divides (inverse of time is a constant for the whole frame and should only be done once per frame).
Standard performance tips apply: Since it is per-bone, if it is too heavy, reduce the number of bones etc. But compared to what has to be done to the bones involving matrix multiples etc., this extra overhead will likely go unnoticed, so overall I would just say, “Negligible”.


L. Spiro

[kuramayoko10]

Wow, it is really amazing those animations and physics. I have never seen anything quite like it *_*

Another awesome thing is the illumination & shadows. The light blends really well with the environment (outside and indoor) and the shadows are very smooth and dynamic

[frob]

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?

Edited by frob, 19 November 2012 - 01:48 PM.

[Madoc]

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

[Cornstalks]

Cool to have you stop by, Madoc. If you're able to, could you share any details of the physics system? I'd love to hear about it from the developer. I'll ask some specific questions, but if you're not able to answer them, no worries:

• How many rigid bodies can it currently support (on an average target user machine)?
• When it comes to importing the meshes to the physics system, are they converted to a low-poly version and fit with convex hulls?
• Any details you can share about the physics+animation combination would be cool.

[TheChubu]

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?

I dont understand the point of your answer. They're not using middleware and I didn't mentioned it. Did you meant to quote somebody else?

Besides, as I said while its a lot of money, given the scope of the project it sure looks like they need it.

EDIT: Weird deja vu for some reason.

Edited by TheChubu, 20 November 2012 - 08:23 PM.

[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 www.youtube.com/watch?v=OPrOonmaG00). 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 .