Is a physics engine useful?

Hi,
I am trying to make a First person game in three js. I want the camera to be the players eyes. I am using the orbit controls, using keys on the keyboard for the movement of my player. But the camera is going through objects and I don’t want that to happen. I researched a lot about this issue and majority of people say to use raycaster but I don’t think it will work in my case since I am not seeing the player … the ray would be drawn from the camera which I think would only alert me of a collision when the camera would be inside the object. Also I have not found a single solution to actually stopping the camera (player) from entering the object. I am working with obj imported models which makes it a lot more difficult too.

I am wondering would a physics engine like ammo.lab sort this issue for me?

Thanks for all the help.

1 Like

I personally use Physijs, because initial physics primitives (ball, cube, etc) are easily created., also I like having the actual physics engine running in a worker. Other use cannonjs.

There are lots of options and a lot depends on your application. Physics engines are great if you need complex physics calculations, simulating various objects reactions in the real world etc. However, if you only need simple stuff and collision detection, often times you can get away with less expensive solutions, like :

  • bounding box collision
  • raycaster & navmesh
  • collision mesh

@druidhawk Does Physijs still work with latest Three? I thought it was outdated

See Preferred physics engine (cannon.js, ammo.js, DIY...).

For just player controls, if you don’t need other physics, a navmesh used with the clampStep() method of three-pathfinding can be used too. It’s cheaper, but requires you to create the navmesh in advance.

1 Like

My current threejs version is “103dev” (as defined in three.js file) I use Physijs in my game extensively without any issues. It is no longer under active development so that’s what you get.

For me the biggest advantage is the syntax below, where both the primitive physics and threejs shapes are created. Just simplifies my dev.

var box = new Physijs.BoxMesh( new THREE.BoxGeometry( 4, 4, 4 ), box_material );

While navmesh is intriguing, the only way I have to generate one is with a back level blender. The newest release does not (or didnt when I checked) support the generate navmesh capability.

If you are running around, collision support simplifies triggering particles, sound effect, etc.

Yeah, they removed the game engine from Blender, including its navmesh-creation features. Probably a good decision overall, but I do miss that particular feature. I use these two sometimes:

Hopefully today or tomorrow, i’m going to post a demo that uses real time navmesh generator using re ast or ammo.js for fps movement. I’ve been wanting to do that anytime soon, already had a prototype

Thank you to everyone who answered! The scope of my project changed a lit so I won’t need the physics engine for now but it was interesting to read all your opinions.

I was reluctant to use Physijs because I didn’t know if I would run into compatibility issues with newer versions of Three.js. Glad to know it still works without issues. Do you know if the Physijs Mesh works with BufferGeometries, or is it just with Geometries?

dommccurdy: I find I am uncertain of aframe vs threejs, your aframe-inspector-plugin, is it compatible with threejs?? Is this only a VR setup, cause my tired IMAC cant do that.

waverider404: did I see you navmesh generator posted anywhere??

Sooo…in reevaluating my game design, I have been using a mix of behaviors and physijs. It may be running into some performance issues as things expand. If I have 20 orcs seeking/wandering etc., each with a physics box (that requires manually dirty flag updates to tell physijs that a behavior adjusted a position) I can still fire a physics cannonball, get collisions with an orc, and blow it up. Sadly manually adjusting N physics bodies, realtime, is starting to degrade performance <50FPS for physics engine. I simulate physics continuously so I dont miss a collision by moving into something before collision checking.

I suspect a test of a 100 orcs/knights/cannons is gunna be slow motion at best on my 8G imac. While not the best GPU/MEM setup, I had hoped that using this would force tight performance coding on my part.

Another issues is agent intelligence, i would like an agent to support say, target detection, physjs does not support a ‘ghost collision’, a detection but not reacting, to a collision, I had hoped to collide with an enemy, and launch attacks, without bouncing away.

I really need some perverse mixture of behaviors/physics/things suggested by dolphiniq. YUCK …redesign in my future.

I would advise you to make a game design document where you list: 1.All the agents, game entities and how they interract with each other 2.All the features you need to support 3.Which things you can solve with three.js alone, and which things will require external tools.

Once you present us with a clear #2, you will have a better design outline, and we will be able to give better solutions for #3. It’s very helpful and will provide you insight into which features you can afford and which you can drop. You might find that some ideas are not necessary at all :slight_smile:

1 Like