Non-realistic, rudimentary physics

Questions
1

I’d like to prototype a game with some very basic physics. As simple as the games that came before realistic physics engine. Think of any other older game (Quake 1/2/3, UnrealTournament 1/2 etc).

I want to avoid rotations on X and Y axis, bounces, objects getting pushed away, forces and accelerations… I just need that moving objects don’t end up overlapping each other.

What’s the best way to write a game like that? I couldn’t find much information on the topic.

From what I found in the documentation, moveWithCollisions seems ideal.

I’m wondering:

  1. is that the way to go? I see no drawbacks compared to using a physics engine. Can anybody think of any?
  2. Is there any more in deep documentation on how moveWithCollisions work? The documentation I found lacks many important details. It doesn’t even say that collisions with plane meshes are supported. Does the collision/intersection engine support anything else besides plane meshes and ellipsoids?
  3. Would it be possible to use AABBs rather than ellipsoids for my objects?
  4. Do I need to create a Plane Mesh for every piece of wall, ground or surface that the objects must not traverse? Won’t that have a bad impact on the renderer? Is there any way to remove them from the renderer’s scene graph, while letting them detect collisions?
  5. If I wanted to use a physics engine instead, how would I need to define the map? Any examples on this?
2

Welcome to the forum. This might be of interest Intersect Collisions - mesh - Babylon.js Documentation

1 Like
3

Thank you.

I did see that 101, but I don’t think it addresses my questions.

4

Hi Peoro and others!

https://playground.babylonjs.com/#6QF3KP#19

Just for kicks, I plotted a special double-walled topless box. You can think of it as a 20x20x20 solid cubical block of wood, with an 18x19x18 cubical hole cut into its top. Boolean-subtract folks can think of this… as a slightly smaller box… subtracted from the initial box. It is a single mesh.

My hopes… was that an AmmoJS meshImpostor… would allow the “dropbox” (a small box impostor falling from above)… to enter the “inner volume” of the blankmesh meshImpostor.

As you can see, it works (I had some problems, earlier… fixed it… so text deleted from this post.).

The little blue boxes with numbers… are just helper boxes… which assist me with the hand-plotting. You can disable them at line 48. Also notice line 168 - blankmesh.visibility = .99; Some may want to change .99… to 1.0 .

No solutions for peoro, yet… just testing things. Could set an invisible physics-active box… parented to camera… with fixedRotation setting. There’s possibilities for using meshImpostors and physics engines. It would be a fun perf test… to have VERY BUMPY inner walls/floor. :slight_smile:

Stay tuned for more comments/ideas… from others.

5
  1. The worst impact I’ve seen on the renderer is too many meshes. Try to control your overall mesh count. Collisions with meshes of high complexity/many vertices can also be costly, consider hitboxes or as you say planes in such cases.
1 Like
6

@withADoveInOneHand: exactly. I thought I had to use a plane mesh for every “wall” of my map in order to use moveWithCollisions, and that would have been bad for the renderer. But it turns out I was wrong.

@Wingnut, wow, nice demo. So, what you’re suggesting is to define the map as a single mesh with physics enabled and have everything animated by a physics engine?

I think it would work, but wouldn’t a single mesh for the whole map be expensive? Everything would always detect a collision with the map in the broad phase, and testing for collisions in the narrow phase against a complex mesh would have a big performance hit on the physics engine.
I believe it would be better to define each wall independently from the others, in order to maximize the physics engine performance, although this would be bad for the renderer.

Anyways, I tried to hack your demo to see how various approaches would work: https://playground.babylonjs.com/#6QF3KP#21

  • With AmmoJS everything works as expected.
  • With OimoJS the dropbox stops on top of the open cube. I guess they stop at broad phase collision checks?
  • With CannonJS the dropbox ignores the cube completely. If we drop a sphere instead of a box, then it works as expected (as documented in “Use Advanced Physics Features” can’t link to it, because of “Sorry, new users can only put 2 links in a post.”).
  • With moveWithCollisions everything works as expected.

I was surprised to see mesh inspectors work with AmmoJS, since the documentation doesn’t mention it.
But what really baffled me is that everything work with moveWithCollisions too. I’ve been experimenting with it further (see https://playground.babylonjs.com/#3B3135#14) and realized that it always does a full precise check on arbitrary meshes (like CannonJS with mesh impostors and spheres). It even ignores the ellipsoid sets on those meshes.

7

Not much animating (of any physics active mesh that the camera is parented/linked-to). If you have floor friction high, restitution low, and fixed-rotation (on the camera’s physics-active mesh)… then the camera will just sort of stop when it hits a wall… no bounce, no slide, no turn. Cameras are not a mesh, and physics engines only work-on mesh. SO… that is why a mesh needs to attach to the camera… somehow… in order to have a physics-active camera.

But it is not easy to nav a camera that has been parented/linked to a physics-active mesh (maybe invisible). It takes things like setLinearVelocity and setAngularVelocity on the physics object… via cursor or WASD keys… and the camera simply follows-along. A user named @givo was recently working-with navigating a physics object with a camera attached. You might wish to see what posts/playgrounds he has made. Not many try navigating a camera with physics.

More brief… in your case (rudimentary physics) we ONLY let the physics engine do the collision-testing on a single-mesh room… via the meshImpostor (which sort of accepts ANY shaped mesh). No bounce-off (restitution), no sliding (friction). Minimum/no animating… just stopping things at the walls, mostly.

With physics engines, .moveWithCollision is not used… nor is .checkCollisions = true, nor are ellipsoids. Different system. (It takes a while to get used-to the differences in the systems).

Cameras are not mesh, so when using physics engines, the camera SHOULD BE parented to a physics-active mesh. But this makes the mesh… THE BOSS of the camera… so we must use physics commands to turn/move the camera… not easy.

The only real reason why I tested a physics engine for in-room collisions… is to allow you to make the room/building out of a single mesh… without having to use many wall-sections and lots of .checkCollisions = true (used for non-physics engine colliding and freeCams - FPS Shooter games).

.moveWithCollisions is really a “barely legal” method… as it is moving mesh. The BJS built-in collision system was initially designed to ONLY use a freeCamera and its .ellipsoid… colliding with stationary mesh obstacles and THEIR ellipsoids. That system was never meant to .moveWithCollisions MESH… but some mad-scientist inventor added .moveWithCollisions… to move mesh into other mesh. I believe .moveWithCollisions can cause “stuck in collision” situations. Again, NONE of that stuff… is involved in physics engines. They are a different system. It’s easy to get the two systems confused/overlapped.

Umm… let’s see… Oimo doesn’t have a meshImpostor, as far as I know. Basic shapes only, for Oimo.

SOME nav-with-physics-engine was done here… https://www.babylonjs-playground.com/#IFN77Q#13
Also check #14, #17, #23… all use WASD keys… and no camera turning, yet. Only linear movements, so far. @givo MIGHT have stayed with this playground series… for his advanced tests… so check #30, #40, #50, etc. I know he advanced the project somewhat. These playgrounds are just “a taste” of what physics-engine “navigating” is like. :slight_smile: Floor friction is everything, along with angularDamping and linearDamping :open_mouth: .

Interesting non-physics-engine PG: https://www.babylonjs-playground.com/#LYCSQ#250

I might have more comments after I read your post a bit better. Good research you are doing!