Point based physics engine

Started by
11 comments, last by koteko 9 years, 6 months ago

Hi all, first post here. I hope it's the right section.

I'm developing a small game for learning, and I was wondering if you knew a free/open source game engine that would fit it well, or else some tutorials to avoid common pitfalls so I could brew my own.

These are the main characteristics of the game world, from the physical point of view:

  • the world is a 3D cartesian space
  • objects only occupy a single point, that is they all have 3 coordinates (x, y, z)
  • gravity pushes objects down on the z axis, other forces may act on the other axes (if an object is thrown horizontally, it must fall both down and horizontally)
  • different objects can have the same coordinate in space
  • certain points in the space can be blocked, for example if I block the point (0, 0, 0), an object initially on (0, 0, 10) will fall (because of the gravity) for 9 points down and stop at (0, 0, 1).
  • For now, impact is not considered between objects or when they fall on the "blocked points", however I should be able to query the physics engine to implement the right game logic (to know, for example, if an object is still falling down or has reached the "floor", in which direction it's moving, with which speed/acceleration..)
  • objects can "die" and be removed, and new objects can be spawned

I'm using Java, so I'd need either a pure java library or one with bindings (like Box2D).

I'm sure I could tweak a 2D or 3D engine to achieve this (arguably very simple) simulation, or write my own as I had started doing, but for the former, I fear it would be like using a Ferrari as a catering van, for the latter I'd like to focus more on the game logic and learn the physics as I go.

Also, there is a certain focus on speed, as the number of objects can grow quite a lot and they do have a good amount of game logic - so I'd like to spend the least possible amount of time on the physics step.

Any advice welcome. Thanks!

Advertisement

I've forgotten to add that I don't need rendering. I "just" need a library to handle the most important parts of the simulation.

I've been searching a lot to no avail - my physics knowledge is little and rusty. Can anyone provide any pointers or better terms than the naive ones I've given, so that my search can be more focused?

My guess is what I need is a "dynamic physics engine" implementing Newtonian physics and collision detections on (also) points. But most of the stuff I've found is for rigid body dynamics and soft body dynamics.

It's not likely that you'll find an engine that deals with points, as classical physics deals with objects that have extent, shape and mass. In addition, it's not clear from your description whether your intent is to use real numbers (a number with a fractional part) or integers, as you mention an object dropping 9 "points" and stopping** at (0,0,1) if blocked at (0,0,0). I think you will find that available physics/collision engines, in addition to using finite objects (vs infinitesimally small points), use real numbers (floating point).

** as opposed, for instance, to stopping at (0,0,+particle-radius).

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Yep, I feared that. However I do remember lectures of physics dealing with dimensionless points with cartesian coordinates. It's been too long though. Possibly it was Kinematics rathern than Dynamics. Mass can be present - just the size of the point should be transcurable. The usual formulas to change acceleration through a force, than changing velocity due to acceleration and in turn changing position due to velocity, they all apply. It would just take me ages to put the equation in, as I'm very, very rusty on this stuff.

Regarding the numbers, it's not a big deal if the engine/library uses real numbers. In the game logic I can approximate the position to the closest integers in all 3 dimensions and put the object onto the discrete grid I guess.

Actually thinking about it, I could use an object with "extent and shape" as you say. If my objects were spheres with radius of half the "unit" (say, 0.5 meter radius), and in the game logic I approximated the position of the center of the sphere to the closest integer (in all 3 dimensions), I might get what I want.

Can you advise on a decent library usable from Java that does have bounding spheres?

I'm not a Java programmer. However, googling for "java physics engine sphere" yields ~17 million hits, including JBox2D (apparently a Box2D port) and several youtube videos that should get you heading in the right direction.


It's been too long though ... I'm very, very rusty on this stuff.

Been there! wink.png Before trying to integrate a particular library, you may want to spend some time brushing up on Newtonian physics, as that will likely ease the pain.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Indeed. Thanks for your help ;)

Were you perhaps thinking of simulating it more like fluid physics, where the points interact with each other through forces based on distance? Like atoms and other realistic thingys.

Since that would give them such an 'extent' (although blurry) of sorts.

If all the points had a limited radius of influence, you could use a hash map or a grid to do the physics in O(N) (since for each point, you only have a fixed number of surrounding grid cells to check, and only a very limited number of other points can fit in those cells) I think... :|

It would be almost equal to having integer coords and only interacting with points in adjacent coords. Just a bit more detail.

o3o

Uhm no I wasn't thinking about fluids, and I don't know enough about them to tell if they are applicable to what I need :)

Here's an example of the functionality I had in mind:

- Point A is at (0, 0, 0) moving 1 meter per second on the positive x direction ("east" in common language)

- After 1 second, A is a (1, 0, 0), where point B is in a static position (velocity = 0). The collision is not acted upon at this level.

The physics engine would be moving around objects using just three things:

- acceleration

- velocity

- position

And changing the acceleration only when told to do so externally, by the game logic. Friction for now could be ignored.

The game logic would usually call World.getCollisions(point) on point A and get back a list of points having exactly the same coordinate, and also in a different context call World.getPointsInRadius(point, radius) to efficiently get all points in the spherical area around the point determined by the radius.

I was thinking on implementing it manually, as it shouldn't be too much of a big deal, but I'm especially worried about collision detection - looking up neighbouring cells with an hashmap sounds like a killer.

Ok I see, so you want basically a grid based (3D) game with physics?

What I was thinking is that give each 'point' a float position to make the physics smooth.

However, you could still have the physics rely on the grid cells - a point may only interact with neighboring grid cells.

I did something similar for a 2D grid game, because I wanted the player to be able to stand anywhere, not just at the center of a grid cell. But the collision detection still worked based on grid cells (the player was 1 grid cell sized square)

What I did was to have a normal grid for the world (you know, grass in this cell, stone here etc.)

And each moving entity had:

-Float position, velocity

-Integer position (grid position)

And the physics applied velocity to the float position, which was rounded to get the grid position (so it can find neighbor cells to do collision detection, like if in a cell above ground, limit the float position from going too low into the ground).

o3o

I think that's a good idea. I wasn't taking into consideration the fact that using integers for the position means I'd have to make my unit length definitely less than 1 meter. Silly me.

I'm brushing up on my physics, and implementing the system using floats now. It's good stuff to learn anyway. Thanks for the pointers!

This topic is closed to new replies.

Advertisement