Jump to content

Best way to move a player within Physics Simulation? (OIMO)


Stephen Andrews
 Share

Recommended Posts

I am attempting to create a game in which the player realistically collides with objects (or at least doesn't clip through them), but have run into a bit of a problem.

 

The player must be able to rotate on all axis, as well as translate on all axis. (Local space) See here: http://triblade9.wc.lt/steelprivateer/

However, the player should also collide with the "asteroids" (debug spheres).

 

It was a simple matter getting the engine set up, and the imposters attached to the meshes. (congratulations on making a simple, robust physics engine binding ;))

 

The real issue comes when attempting to move/rotate the player.

 

Here's what I've tested:

  • Using the mesh.rotate and translate methods in local space like normal, and updating the body position - Result: Rotations don't work and the body position updating causes lots of jittering.
  • Directly modifying the rotation vector, continue to use translating and updating body position. - Result: Weirdest, most confusing rotation system ever, "forward" seems to be a combination of random axis or something. Example (Yes, I know the rotation coordinates are not global, but the "forward" direction seems off)
  • Using mesh.applyImpulse. - Result: Incredibly finicky to get a solid directional push, very quickly goes berserk when rolling or pitching.
  • Using mesh.moveWithCollision - Result: Similar to #2, but the 'forward' direction seems even weirder.

I will upload an example of #2 soon, the Babylon playground isn't working for me with Oimo.js at the moment.

EDIT: Example linked.

Link to comment
Share on other sites

Have you tried moveWithCollisions?

 

i.e mesh.moveWithCollisions(new BABYLON.Vector3(0.1,0,0))

EDIT: Isn't that for the inbuilt collision system? Not the physics engine?

 

No, I have not. Is that documented anywhere? I'm having more of a problem with rotations then moving, is there a similar function for rotating?

 

Does it work in local or world space?

 

I will check the babylon sources later, gotta go to work.

 

EDIT2: Nope, that just got weirder. 

Link to comment
Share on other sites

Hey again. :)

 

Physics is currently broken in 1.14. Specifically updateBody is slightly outdated for some changes to registeredMesh.

 

See the pull request one of my guys just put in: https://github.com/BabylonJS/Babylon.js/pull/301.

 

(Depending on when you click this link, it might only contain the fixed for the cannon plugin; we just noticed from your message the the oimo plugin is also broken. )

 

As soon as that's merged, your first should work for you.  :D

Link to comment
Share on other sites

Hey again. :)

 

Physics is currently broken in 1.14. Specifically updateBody is slightly outdated for some changes to registeredMesh.

 

See the pull request one of my guys just put in: https://github.com/BabylonJS/Babylon.js/pull/301.

 

(Depending on when you click this link, it might only contain the fixed for the cannon plugin; we just noticed from your message the the oimo plugin is also broken. )

 

As soon as that's merged, your first should work for you.  :D

Oh wow, thanks a heap! I had no idea the plugins were broken. I'll test ya'lls fork in a bit and see how it goes.

 

EDIT: I would be testing it now... If I could clone the repo faster than 3kb/s. Whoo China internet. >_>

Link to comment
Share on other sites

In an attempt to stay vaguely on topic, I'm going to reply to this post here, and let the skybox post die.

 

Basically, we've fought the beasts of doing physics based movement a couple of times, and have always had some level of success. Over the years, what we've settled on is a system we call 'target velocity'. Basically, you just specify the angle and velocity you want the physics body to move at, and it will apply forces and accelerate, attempting to stay as close to that velocity as possible. This works both for linear and angular velocities. (Note: angular velocities are in Local space to avoid Gimbal Lock issues.)

 

Currently (and I mean, as I write this, we're all hacking on the code) we're trying to port the system over to cannon.js as a node/browserify module. (If you want to follow it, check it out here: https://github.com/SkewedAspect/rfi-physics. Just keep in mind it's a 4 hour old project.) The end goal is that this pretty much handles all the heavy lifting of setting up a physics system, and doing really nice, easy to integrate movement. Now, our intention is to have 'arcade' style collisions (completely inelastic), instead of 'real' (elastic) collisions. If, however, you wanted to have realistic ones, it wouldn't be hard to make the target velocity simply add torque/forces, as opposed to setting them directly.

 

Let me know if you're interesting in out approach, and we can plot to make it something that maybe the Babylon.js community can benefit from... or at the very least our mutual projects.

Link to comment
Share on other sites

In an attempt to stay vaguely on topic, I'm going to reply to this post here, and let the skybox post die.

 

Basically, we've fought the beasts of doing physics based movement a couple of times, and have always had some level of success. Over the years, what we've settled on is a system we call 'target velocity'. Basically, you just specify the angle and velocity you want the physics body to move at, and it will apply forces and accelerate, attempting to stay as close to that velocity as possible. This works both for linear and angular velocities. (Note: angular velocities are in Local space to avoid Gimbal Lock issues.)

 

Currently (and I mean, as I write this, we're all hacking on the code) we're trying to port the system over to cannon.js as a node/browserify module. (If you want to follow it, check it out here: https://github.com/SkewedAspect/rfi-physics. Just keep in mind it's a 4 hour old project.) The end goal is that this pretty much handles all the heavy lifting of setting up a physics system, and doing really nice, easy to integrate movement. Now, our intention is to have 'arcade' style collisions (completely inelastic), instead of 'real' (elastic) collisions. If, however, you wanted to have realistic ones, it wouldn't be hard to make the target velocity simply add torque/forces, as opposed to setting them directly.

 

Let me know if you're interesting in out approach, and we can plot to make it something that maybe the Babylon.js community can benefit from... or at the very least our mutual projects.

I'll definitely keep an eye on that, it seems similar to what I want to do, though avoiding direct physics-based movement would be preferable. (Not trying to be realistic here)

Link to comment
Share on other sites

I'll definitely keep an eye on that, it seems similar to what I want to do, though avoiding direct physics-based movement would be preferable. (Not trying to be realistic here)

 

It's a bit of a mixed bag, tbh. What we're calculating is technically forces and torques, and trying to short circuit the physics engine entirely involves building your own Runge Kudda 4th order integrator, which isn't fun (Unless you go in for that sort of thing :P ). What we opted for is a much more pragmatic approach; we calculate just enough to set the properties on the rigid body, and let the the physics engine do the rest. It means we need the physics engine, but we're not letting it do much more than calculate our velocities for us, and let us know if we collide. We keep tight control over the rest, resetting the torque/forces every frame.

 

Provided we have any success with this approach, it should yield the best performance to effort ratio. (And it's a huge win on the maintenance side.) Here's hoping!  :D

Link to comment
Share on other sites

That's awesome! How exactly do you get it to tell you when you collide? I haven't looked very hard, but haven't found anything related to that yet.

 

Just listen for the 'collide' event on bodies in cannon. Pretty easy.

 

By the way, we should probably move any more game-specific talking to PMs, we're sort of cluttering up these threads.  ;)

 

Agreed. Though this might be incentive for me to finally get some sort of forum of my own setup again. Used to have some, but the server died a few years ago...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...