tyree at February 26th, 2013 07:13 — #1
has anyone used an engine that lets the characters position be controlled by animation and it works with the collision system. this should be a common thing. but its surpisingly rare. and unity 4 doesnt qualify. doesnt work with imported rigs
fireside at February 26th, 2013 09:31 — #2
Maybe you could give an example of what you mean. All the engines I've used, which amounts to 3 or 4, the position of the character was dictated by code. I've found in unity, when there is a door that opens and closes, I have to attach a collision object to the bone I used. I haven't used Unity 4 yet.
tyree at February 27th, 2013 16:54 — #3
you have the right idea the opposite of dictated by code. a character with a walk motion of only 5 steps forward, not in place. once the fifth step is reached the character, keeps going forward, instead of moving back to the position of the first step location. which would be 4 steps behind it now.
triggers will always have to be done by a collision object. I dont mean triggers but dont walk thru walls collision be it raycasting or physics
fireside at February 27th, 2013 23:19 — #4
That would get a little complicated for turning, etc. I don't know of any engine that does that. The entire animation cycle would have to be translated forward to the right position and a collision object attached to a main character bone or bones so it moved within the animation cycle. Changing animations would be a nightmare. It seems like one cycle would be enough to stop foot slip, but would still be complicated. What would make more sense, to me, would be to measure the forward motion and repeat it in code in the game. Mainly it comes from the character actually speeding up and slowing down during a walk cycle, so advancing in a steady movement doesn't quite look right.
reedbeta at February 28th, 2013 01:06 — #5
Our engine at Sucker Punch actually does do what tyree describes, I think. When the animators create a walk cycle, they animate the character actually walking forward in her local space, not just walking in place at the origin. The tools detect this and extract the root motion (the "root" being defined as the gut joint, projected down to the ground plane, or something like that). Then the animation playback speed is scaled at runtime based on how fast you want the character to actually walk, using the root motion to ensure there is no sliding. I think we use additional authored animations for starts, stops and turns as well.
tyree at February 28th, 2013 04:39 — #6
actually fireside it looks great. when a character is being moved forward by animation be it walk, run whatever it may be. if you want the walk or run to be slower or faster. you can code the animation speed in the engine. turns are usually coded. when the turns are combined with the forward motion it looks pretty nice. but as reedbeta points out turns can also be done with animation. if you want to beauty it up
what reedbeta describes about how thier engine works hits it on the head. if anyone becomes aware of such engines post about it. thier are far too few
collision objects will be attached to the bone. be it in place or forward motion. that really shouldnt make a difference. once an object is parented to another object. it never looses its position. if it does thats just a terrible engine
fireside at February 28th, 2013 08:38 — #7
I can see where that would be the ideal, but it's a little much for an amateur or indie game in my book unless it's pretty easy to do in a modeler and the engine takes care of everything. Interesting discussion though. I didn't know they were doing that kind of thing. I think it is done in most modelers, even in Blender. I could be wrong about that, but I remember reading something about it. I think mostly it has to be done in a standardized way so it can be included in an FBX or whatever file so the engine would know how to handle it.
thenut at February 28th, 2013 08:39 — #8
I don't see that as an engine feature that needs to be supported. It more or less falls on the animator and programmer how they want to implement animations. Most engines just support skeletons and the rest is up to you. Having the animation control the skeleton has the added benefit of accurate stepping, but I wouldn't speed up the animation to accommodate a different state. A walking animation shouldn't be sped up to simulate running. Running faster doesn't just mean your legs move faster, it could be that you take longer strides too. I would implement such a system primarily for proper stepping, but also to make the animators job easier since they can animate full sequences and splice it into loops and transitions.
Interacting the skeleton within the environment (via collisions or more commonly through sensors) however is quite rare. It's not uncommon to see a foot penetrate a slope in the landscape or have animation cycles that don't match with the environment (like walking up 1½ steps). I don't think that could be algorithmically solved in a general sense. You need to include special animations for that or write specific IK behaviours using triggers in your environment to control the bones. Something I don't think could be native in an engine.
vilem_otte at February 28th, 2013 10:28 — #9
#Nutty - What about dynamic IK? That could solve it in a *general sense*, couldn't it? (But it depends what actual general sense is in this context - just walking, running, etc. should be okay ... but more complex movements won't look okay or the simulation will totally fail).
tyree at March 1st, 2013 05:10 — #10
to the nut with feet penetrating the ground thats the collision system. being used at work and most likely looping in place motion. with speeding up the motion, a use would be having the character pick up speed while your holding down a button.
with triggers you dont need dynamik ik. just a trigger telling the character when to play an animation will do. if a character doesnt walk up stairs right. the developers most likely didnt feel it was worth correcting or left it up to the collision system.
triggers arent used more often, because, well you all know the trend. leave everything up to the physics system and we will live with whatever results we get, from the physics system. but its not the only way to get interaction
every route other that a using physics for interaction is becoming more forgotten. but its most certainly not the only way. with 1 and a half step. you really shouldnt be a able to walk up half a step. it should be one full step up or down but not a half
thenut at March 1st, 2013 15:02 — #11
Dynamic IK is definitely a prerequisite for the solution, but it is more commonly used for ragdoll physics. Algorithmically controlling the movement through dynamic IK and collision detection is not easy. You're likely to run into all sorts of problems such as hitting bone constraints and having a natural reaction to that. When a slope is to steep for example (mountain climbing), your foot doesn't parallel with the slope and slide down, rather it stays flat and the ball of your foot is used to grip. Or when you turn your character and a component ghosts through the wall (very very common). How do you solve that? Do you bend the component like a feather or is it stiff and your avatar is no longer allowed to rotate? This is why I stated it's a complicated problem to solve algorithmically. The AI controlled animation suite that was posted here a while back looks like the most promising solution and I believe that's based off dynamic IK, sensors, and of course extensive learning/training. Like lip-syncing, I don't think these are features that will be inherit in game engines. Perhaps not yet, but more commonly in the future when all these start-ups get bought out.