Jump to content
  • Advertisement
Sign in to follow this  
jrh2365

Unity Player movement without physics engine

This topic is 1421 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm curious as to what sort of techniques exist for handling player movement in a 3D environment without the use of a physics engine.

 

One approach I've tried in the past was using sphere casting (performing multiple iterations to handle sliding), but it had a number of quirks that I couldn't easily resolve.

 

Another thought I had was to just move the player along a navmesh, as described in http://digestingduck.blogspot.com/2010/07/constrained-movement-along-navmesh-pt-3.html. The main thing I'm still unsure about is how to handle dynamic obstacles (ex. enemies). And most of the navmesh resouces I've found so far pertain to the implementations in Unity, Unreal, or Source, rather than how to actually implement it.

 

Any thoughts on the above or alternative techniques? Or good resources on implementing them?

 

Also, are there any commercial games using similar approaches? From the small amount that I've played it, I think Kingdoms of Amalur: Reckoning might be using an approach similar to the second one I described, but I'm not sure. 

Share this post


Link to post
Share on other sites
Advertisement

..without the use of a physics engine.

 

First, a little clarification - the various types of things you describe are better termed path-finding, collision engines or collision detection. Physics engines normally deal with object mass, velocity, angular velocity, etc., and the responses to collisions, which doesn't sound like what you're talking about.

 

Second, the topic title is "Player movement.." Do you mean a player guided by a user, or NPCs, perhaps guided by AI?

 

As it seems you're asking about collision detection, I suggest you look into the Bullet or ODE (Open Dynamics Engine) libraries, both of which implement collision detection, and (IIRC) can be setup to use the collision detection parts separate from the physics parts.

 

With regard to collision detection techniques, there is also raycasting (also implemented by Bullet and ODE, BTW), which is a technique for specifying a position and direction (a "ray") and calculating intersections with various geometries. That technique could include spheres or capsules representing "dynamic" objects moving about.

 

You could also look into "sweep and prune" or "swept volumes."

 

Without details of your needs, it's difficult to provide more specific information.

Edited by Buckeye

Share this post


Link to post
Share on other sites

Are you referring to perhaps games like diablo, where the movement of the player is abstracted?  In a diablo style game, technically you don't need a physics engine, the player character just moves to wherever a valid click is, so essentially the pathfinding is doing all the work to guarantee there are no collisions.  (it still has to check for collisions, but there would be no collision response)

Share this post


Link to post
Share on other sites
Let me see if I can explain this better. I'm looking for approaches for controlling the movement of a player character (guided by the user), that do not use a physics engine (using the collision portion of Bullet is fine). So a non-physical or non-dynamic character controller, which would seem to be considered a kinematic character controller? (Though I'm not sure if the second approach below would be considered a kinematic character controller)
 
1. The approach that I have attempted to implement in the past used only the collision portion of Bullet to perform sphere-casts against a triangle mesh representing the world. So it calculates how far a sphere can move in a certain direction, and if that distance is less than the desired movement direction, it then projects the movement vector onto the surface that was hit, and performs another sphere-cast to allow for sliding collision. It might repeat that a couple times depending, and also does another sphere-cast in the vertical direction to handle y-velocity and stepping-down (to avoid floating/bouncing while moving down an incline. I believe that was also used to determine whether the player was standing on the ground. There were a number of issues that I ran into with this approach including getting caught when sliding along certain geometry, jittering in obtuse corners, and bouncing along the edge between the ground and a surface that is considered to steep to walk on.
 
2. The other approach is one that I have not attempted to implement yet. It would involve using a navmesh similar to what would typically be used to handle NPCs, except for the player. This is a slightly more limiting than #1 in that the player is constrained to the navmesh. Even though the player could jump, they could not, say, jump across the edges of the mesh (ex. over the edge of a staircase back to the floor). They basically move around within a triangulated 3D polygon. There would be no real collision detection between the player and the world geometry. One of my current uncertainties with this approach would be the handling of other obstacles (ex. enemies moving around).
 
So I'm wondering:
  • Are the above approaches actually used?
  • What other approaches exist?
  • Are there any good resources on implementing these approaches robustly?

 

 

Rough sketch of #2

[attachment=24007:second.png]
 

Share this post


Link to post
Share on other sites
Very often there are multiple sets of data. The physics ground is one object, the rendered terrain is a second object, and the navigation mesh is another.

A navigation mesh can be very simple, even a 2D grid that maps onto the terrain. It can also be complex, a full triangulated mesh or even a volumetric representation.

Games will often have multiple parallel representations internally, a fact often surprising to new developers.

I've worked on several games that people think of as bigger 3D worlds but in reality were just 2D grids internally; height is just stacked grids starting at ground level. Players move from cell to cell to cell, animating smoothly along the way. A tiny bit of animation magic and the walked paths can bend and twist organically over the 2D grid yet still move from cell to cell.

Motion is only allowed between areas of a navigation mesh if the two sides are connected. Disconnected edges, like the ramp in your image, are not navigable. They act as a wall or barrier.

What you drew in your image is a great example of a navigation mesh. It isn't a physics mesh since you don't want things to fall off it. It isn't a render model since your stair will will likely have a rail or other barrier. Many times they will have additional information tied to the nav mesh to indicate things like sounds and speed and other attributes (e.g. walking on wood, walking on carpet, splashing over puddles, squishing through mud, etc.)

For your other questions... Yes, they are extremely common. To make them fast people usually break them up with spatial trees, and most of the big articles about loose quadtrees and such are intended for use in navigation meshes with things (like enemies) moving around. There are lots of articles about the subject, you just need to realize what you are looking at. For alternate implementations, you can rely entirely on physics for some games (Super Monkey Ball comes to mind) and you can rely on strict grids for things like board games, but nav meshes with spatial trees over the navigation mesh is really the standard method.

Share this post


Link to post
Share on other sites

Jeff

 

1.  This method seems like you're basically doing your own form of collision response.

2.  This method seems like the diablo method I mentioned before.  I've implemented variations of it.  It was pretty trivially easy to for example, get a the ray from a click on the screen, find where it hits the navmesh and then have the player-actor try to navigate to that point on the navmesh.  You are correct that jumping doesn't work with that method, one would either need to have jump as connector node type thing(Aliens the RPG was going to use something like this, if I recall correctly) or make jumping physically driven.   Oh, and for enemies and other moving characters, usually a form of local avoidance is used.

Edited by ferrous

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!