2

I've been recently trying to fix my collision detection in my first person shooter three.js game but there are a few issues left I have not even the slightest idea on how to fix...

  • The camera can view inside walls
  • The collisions regularly push the player outside of the map

I have a jsfiddle available here: http://jsfiddle.net/sxv5fwL4/95/

And I have also received a little advice on the three.js subreddit under the post...

"Use of the "stemkoski" collision detection?"

I thank you in advance for your time, and thanks to /u/stovenn for his help in my reddit post.

Wilt
  • 41,477
  • 12
  • 152
  • 203
Andreas Elia
  • 363
  • 4
  • 12
  • Would it not be wiser to use bounding boxes for something like this? – Wilt Mar 02 '16 at 13:14
  • @Wilt Yes, the new version below uses bounding boxes I do believe. steveOw really did manage to do a great job at helping me with the issues I was having. – Andreas Elia Mar 05 '16 at 20:44

3 Answers3

3

i think /u/stovenn talked about this git http://stemkoski.github.io/Three.js/

According to the thread How to detect collision in three.js? in the stemkoski git is a working example for a collision detection in three.js

Community
  • 1
  • 1
ralf htp
  • 9,149
  • 4
  • 22
  • 34
  • Exactly, those examples use bounding boxes. @AndreasElia you should definitely check these examples. – Wilt Mar 02 '16 at 13:15
  • @Wilt Actually the Stemkoski method uses rays, not bounding boxes. – steveOw Mar 02 '16 at 14:22
  • @steveOw I learned something new today. I always thought this example was using bounding boxes internally. – Wilt Mar 02 '16 at 14:28
  • Hi folks, thanks for the replies. Yes, the stemkoski uses raycasting between two meshes (the wall, the cube), whereas I raycast between the camera and the direction it is moving. _/u/stovenn_ has advised me to check out _world-axis aligned bounding-box collision-detection_ which is located at http://stackoverflow.com/questions/25697327/three-js-accurate-ray-casting-for-collision-detection I do believe. – Andreas Elia Mar 02 '16 at 14:31
2

This jsfiddle0 (see end of answer for updated versions) is a hacked version of the one cited. There was a problem with the Map which I have addressed by reading it as [u][v] and mapping Edit: (u-->z and v-->x). Now the layout of the map in the code is the same as the layout of the map in the simulation.

I have used a very simple "(2D) Point in Bounding Box" collision test. It is based on testing whether the proposed new position of the player at each animation step locates inside the x-range and z-range of a wall cube. If it does then the proposed position is rejected and the (stored) previous position of the player is re-instated.

Here is the core code:-

if (   tile_x_min <= player_pos_x && player_pos_x <= tile_x_max
    && tile_z_min <= player_pos_z && player_pos_z <= tile_z_max )                              
{
collision_flag = true;
player.velocity.x = 0;
player.velocity.z = 0; 
Message = "IN Wall Cell [" + x + "," + z +  "]" +
"(x:" + tile_pos_x + ", z:" + tile_pos_z + ")";                                           
}

I have used a little helper cube ("eddie") at the player position and moved the camera back a bit to make it visible. This helped a lot in troubleshooting glitches.

Anyway give it a try if you like and let me know how it goes.

Edit(1) jsfiddle1 Adds simple rotation of the player/camera. Use keys numpad_7 and numpad_9 to rotate left and right.

Edit (2) jsfiddle2 responds to multiple keys being pressed at the same time. Also the eddie cube is hidden by using eddie.visible = false.

Edit(3) jsfiddle3 Added independent camera rotation: up-centre-down (use Numpad keys 2,5,8). Player+camera horizontal rotation is by Numpad keys 4,6.

steveOw
  • 879
  • 12
  • 41
  • Wow, that's exactly what I was after! Thank you! Do you know how well this method of collision would work with camera rotation though? It seems as though I'd need to rotate the cube with the camera? – Andreas Elia Mar 03 '16 at 09:34
  • @Andreas Elia Well it depends on what kind of rotation is required and how the PointerLockControls are designed. Eddie currently adopts the (approved) player position and the camera goes with it. You can rotate Eddie(+camera) easilly enough around Eddie y-axis (e.g. [here](http://jsfiddle.net/xn8wvdt2/22/)) but rotation will change the collision pattern and so the trial would need to include a proposed rotation as well as proposed translation. It needs to be played around with. – steveOw Mar 03 '16 at 10:15
  • [Here](http://jsfiddle.net/xn8wvdt2/31/) I have added a simple horizontal rotation (use keys: numpad 7 & 9). You may want to play with zoom and fudge and camera frustrum near values to fine tune the user experience. NB I am not understanding the PointerLockControls. NB The rotations are not proposed and tested before acceptance - ideally they should be. – steveOw Mar 03 '16 at 11:27
  • Thanks for your help, it is much appreciated. What do you mean by "NB" regarding PointerLockControls rotation using mouse? How does mouse rotation defer from keyboard rotation? – Andreas Elia Mar 04 '16 at 12:49
  • @Andreas Elia. No prob I enjoyed doing this one! Hmmm I don't remember saying anything about mouse, just that I haven't taken time to understand the pointerlockcontrol code so something in my simple solution may not fit well with other things that pointerlock control does. The latest jsfiddle is in Edit(2) of my answer (above). – steveOw Mar 04 '16 at 20:37
2

I am using Ammo.js, an emscripten port of the great Bullet Physics Library. This is a professional, open source, collection detection library.

Here is a sample I created: physics.autodesk.io

Could be useful to somebody.

Felipe
  • 4,325
  • 1
  • 14
  • 19