Adam's Lair Forum

game development and casual madness
It is currently 2019/09/17, 15:23

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Kinematic bodies
PostPosted: 2013/07/08, 20:26 
Member
Member

Joined: 2013/05/20, 17:19
Posts: 77
Role: Professional
Can't wait till there's someone else on here asking questions so I don't look so needy :D

Just wondering why you don't expose kinematic Farseer body types. Looks like we'll need them now, so just wondering if there's a good reason before I go and add that.


Top
 Profile  
 
 Post subject: Re: Kinematic bodies
PostPosted: 2013/07/08, 21:28 
Site Admin
Site Admin
User avatar

Joined: 2013/05/11, 22:30
Posts: 2073
Location: Germany
Role: Professional
There's no hard "you can't do that" reason. I just never experienced a situation in which I couldn't solve a physical problem without kinematic bodies, so I left them out to reduce overall complexity. Kinematic bodies expose some behavior that might be counter-intuitive to newbies:

  • They don't react to ApplyForce / ApplyImpulse and can only be controlled by directly setting LinearVelocity or Position.
  • They don't collide with static or kinematic bodies - as far as I know even including sensors.

I'm curious - what's your use case? And could it be comfortably solved without kinematic bodies? Depending on that, I probably should reconsider adding them to the main branch. It should be a matter of a single line of code, so it's more a design decision.

Quote:
Can't wait till there's someone else on here asking questions so I don't look so needy :D

Well, I guess you could just consider yourself a pioneer in this field ;)

_________________
Blog | GitHub | Twitter (@Adams_Lair)


Top
 Profile  
 
 Post subject: Re: Kinematic bodies
PostPosted: 2013/07/09, 11:38 
Member
Member

Joined: 2013/05/20, 17:19
Posts: 77
Role: Professional
I guess I can live with being a pioneer :rolleyes:

In our situation, we're building a beat 'em up game (which, thanks for the blog post about it by the way, that's awesome) and for the characters, we're using the fairly popular technique of a wheel attached to an upright body using a fixed body joint, with a revolute joint connecting the two. I'm sure you've seen it around, but here's a link, just in case - http://amazingretardo.simiansoftwerks.c ... cs-engine/.

For lots of moves, the characters have to perform some translation so that their movements match what their animations are doing .i.e a character taking a step forward mid-attack should physically translate forwards by the correct amount. The motion paths are either created manually using a curve editor we created inside Dualitor, or imported from a path exported from some DCC tool. Applying the translations is the hard part though because, for the most part, character locomotion is achieved by applying a motor speed to the revolute joint attached to a character's wheel, and this is incompatible with applying velocities and forces manually.

So I was thinking to try out making the wheels kinematic bodies and using raycasts to perform collision checks with the ground and other objects, which should make applying manual translations much easier. Does that all make sense?


Top
 Profile  
 
 Post subject: Re: Kinematic bodies
PostPosted: 2013/07/09, 16:14 
Site Admin
Site Admin
User avatar

Joined: 2013/05/11, 22:30
Posts: 2073
Location: Germany
Role: Professional
Ah, I see.. so the problem is your animation requires the character to physically move in a specific way, but you can't guarantee that by setting the wheel velocity? Your solution approach would be to make the wheel and / or body a kinematic body and just setting their position and/or linear velocities to a specific value?

In order to fully understand the implications of that, I'm going to list up the consequences, as I see them:

  • Your animation will be guaranteed to always be able to apply the appropriate transformations. That's a plus so far.
  • You will have to perform all collision checking and response between body and static world by yourself, because kinematic and static bodies don't collide. Probably not that nice.
  • You will probably have to do the same for colliding two bodies both playing an animation, since kinematic vs. kinematic isn't defined. Could be handled via game logic, but might be a problem because their sensors won't trigger as well.
  • When interacting with dynamic bodies, they might react counter-intuitively while the player is doing an animation - because even a massive stone block would be pushed along as if it was made of paper due to the nature of kinematic body collision.

All in all, you would achieve your goal at the cost of a valid physical representation of your game world. Kinematic bodies are often the point at which hacking begins. It's a valid solution, but it might backfire later on.

But I believe there is a different way. What I've found out during prototyping on my recent project is that you can also achieve platformer character controls not by applying motor forces to the wheel, but also by directly applying linear (horizontal, mostly) world forces to the body. The wheel's purpose will no longer be character locomotion, but to prevent friction preventing directly applied forces from getting stuck. The main advantage is that you can control character movement much better since you don't have to account for wheel / ground friction or the wheel slipping through when accelerating much. Here's a piece of pseudocode:
Code:
body.ApplyWorldForce((this.targetWalkSpeed - body.linearVelocity.X) * this.forceFactor);


When an animation plays, that's again the tricky part. Of course, you can always resort to directly setting the bodies LinearVelocity property in the same way you would with a kinematic body, but it would be (physically) much nicer to instead use some kind of impulse or adaptive force like for horizontal movement. The advantage of a more physically correct and less kinematic approach is that your system should behave a lot more flexible when introducing new physical elements to the level:

Lets say you have an animation where your character pushes something forward. Using kinematic bodies, he would push just anything at the same speed, regardless of its mass and at the cost of other dynamic bodies being flung across the level if they get squeezed between others. In an adaptive force approach like the one for horizontal movement, your character would properly react to the mass he is pushing - being slower or unable to for big masses and moving faster for lighter ones.

Of course I don't know your use cases - you might still be better off using kinematic bodies, depending on the case. But I guess evaluating a non-kinematic physical approach can't hurt, if you can spare the time.

_________________
Blog | GitHub | Twitter (@Adams_Lair)


Top
 Profile  
 
 Post subject: Re: Kinematic bodies
PostPosted: 2013/07/09, 16:32 
Member
Member

Joined: 2013/05/20, 17:19
Posts: 77
Role: Professional
Thanks Adam. Not even directly Duality related, and still an awesome answer!

You understand the problem correctly, and your list of issues with it is bang on. These are all problems I was considering just working around using raycasts and bits of game logic.

The wheel motor approach has been working well so far for us. We don't have any wheel slippage on accelerating as both the wheel and ground surfaces have high friction values (hence my earlier post about exposing higher friction values through Dualitor :) ) but the biggest win for this approach is that acceleration and max velocity are not dependent on the slope of the surface a character is standing on. The wheel motor torque is set to a very large value, and so it just powers over any slope, and handles downward slopes automatically. I guess with your suggested approach it would be possible to figure out the slope of the surface underneath a character and adjust the force being applied up or down depending on the direction of movement, but that sounds...tricky. It might also have the problem that characters go airborne for a short time after cresting a slope. Having said that, these problems seem more surmountable than the kinematic approach, so I'll give it a try first.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group