Physics engine PAPPE integration in ZGE

[VilleK]

BeRo has been kind to offer help with attempting to use his physics engine in ZGE.

This thread is meant to serve as an open discussion on how to best include the engine.

The source code and demos for PAPPE are available here: https://sourceforge.net/projects/pappe/

There is no documentation except for the demo projects, and the 7000-line source file have no comments. Almost like the code for ZGE then

However it looks rather easy to use.

Initialize engine:

Code: Select all

    PhysicsInit(Physics);
    PhysicsInstance:=@Physics;
    PhysicsInstance^.SweepAndPruneWorkMode:=sapwmAXISAUTO;
    PhysicsCollideInit(Collide);

Per object initialize:

Code: Select all

    PhysicsObjectInit(Object,BodyBox);
    [...various calls to define mesh...]
    PhysicsObjectFinish(Object);
    PhysicsRigidBodyInit(ObjectRigidBody,@Object,50,0.5,0.8);

Each timestep:

Code: Select all

    for each object
      PhysicsObjectUpdate(Object,TimeStep);
    PhysicsUpdate(Physics,TimeStep);

Shutdown:

Code: Select all

    for each object
      PhysicsObjectDone(Object);
      PhysicsRigidBodyDone(ObjectRigidBody);
    PhysicsCollideDone(Collide);
    PhysicsDone(Physics);

There are many options to consider for ZGE-support. For one thing the ZGE-models need to add new properties like UsePhysics True/False, PhysicsMass etc. But the main design decision that needs to be made now as I see it, is how to solve state-synchronization between ZGE and POPPE. In other words to make sure that the Model in ZGE with transformations, geometry etc is exactly the same that PAPPE calculates physics on.

An example how zge would be used with an unmodified version of pappe:

Code: Select all

init zge-model
  somehow copy all meshes and transforms from OnRender to poppe-physicsobject mesh
for each time step
  for each zge-Model that have UsePhysics=True
    copy model state to pappe-physicsobject
    call poppe PhysicsObjectUpdate
    move model state back from pappe-physicsobject to zge-model

The other option is to start using a modified version of PAPPE that knows about ZGE-models and can read state from it directly. This would require less data-copying and likely also smaller code-size since the code will be tightly integrated. However it would mean that new additions and bugfixes that BeRo makes to the public version of pappe needs to be manually merged into the custom zge-version.

So these are just my initial thoughts on this, please feel free to offer ideas and suggestions.

[kattle87]

I wanted to know, how much feasible is creating several different ZGE-runtime bins to be included within the ZGE zip file. Let's say one wanted to get a small executable, we forget about complicated stuff like a physics engine and when we go for creating the exe we just pick up the right bin. This way:
-They are precompiled, so no problems for the end user (they would not even notice the difference)
-We can add "size-hungry" features without compromising the 64-kb aim when creating a generic game.

Let's say, 3 or 4 diff bins should be enought for most cases.

[Kjell]

Hi guys,

I'm with Francesco on this, a separate bin that includes the Physics components for people that want to use it ( not me ) would be nice. Perhaps it's possible to add a drop-down box to the Options dialog where you can select the bin you want to use ( and ideally include / exclude components depending on that selection from the Add Component Window ).

Too bad you're going to attempt this instead of porting the Raycast, Matrix / cross-product functions, Bounding-Box generation and other Mesh Collision features that are likely to be found in BeRo's 3D FPS Engine. But I'm sure that people that do like falling crates and ... falling crates will be quite pleased

K

[VilleK]

Ah, yes but I forgot to add that the physics engine of course includes advanced collision handling. And one of the benefits of using the engine would be to replace ZGEs collision handling with BeRo's.

Also the engine isn't monster sized, BeRo is a demo coder so he knows how to keep the runtime small.

And I think most games would benefit from a physics engine, it's more than falling crates you know

[Kjell]

Hej Ville,

Ah, great! That's very good to hear. Most physics engines I've worked with only have fixed or dynamic states for objects, treat phenomena on a global level, force you to work with forces / impulse ( overwriting any non-physics parameters ) and don't expose any of the internal collision functions. Pardon me for jumping to conclusions prematurely.

Personally I never use physics for control / game mechanics. Tends to get too sluggish / floaty with too many running variables for my taste. But
apart from that Little Big Planet is quite ok And the Gravity Gun in Half-Life 2 did have its moment as well.

Anyway, I'm not so concerned with size ( some textures I use are bigger then the ZGE footprint alone ) .. but it would be nice if you could continue to use your slogan "The tool for creating 64kb games!"

K

[BeRo]

My physics engine is called PAPPE and not POPPE

The collision detection is advanced, therefore it has also trimesh vs. trimesh coillision routines, but which should be as possible avoided (if big meshes or very many meshes), and use as possible only Bounding Sphere / Bounding Box collisions. And PAPPE uses sweep and prune for to limit the number of collision pairs of objects. My sweep and prune implementation has 4 modes, X axis only, Y axis only, Z axis only, auto single axis select and all three axises at the same time (by three-axis-list intersection). Therefore PAPPE should be fast enough for small to midlarge games.

And to the topic size. PAPPE grows a compressed EXE only 8kb to 16kb depending on which features of PAPPE are used in the binary.

And my suggestion is that PAPPE in his original state should be used in ZGE, because this would make the cooperation (bugfixes, new PAPPE features, etc.) easier.

[kattle87]

1+ for integration of course. OSS software lives because of collaboration . But I would think about collision-only integration and full intregration in two different binaries...

BTW: I think that if something that brakes retrocompatibility must be done, it's to be done now

[jph_wacheski]

you know me,. whatever you add to ZGE I will endevore to utilise to my limited ablilites,. in my endless persuit of games that i enjoy to make and play,. . even quite simple physics can be used in many ways to create or add to gameplay,. peace

[Kjell]

Hallo BeRo,

Luckily Mesh VS Mesh collisions are only needed under very few circumstances. Ray VS Mesh or Bounding Volume VS Mesh are more then sufficient in most situations, and a much smaller performance hit.

By the way, ZGE features a Collision Group system enabling developers to limit the object combinations between Collision checks are executed. Does PAPPE support something similar to which this can be linked?

Could you elaborate the purpose of the single Axis Sweep and Prune modes? My guess is that in the illustrated situation, when you use X-Axis S&P it uses the extends of the blue ( or does it use the white = non-matrix calculated BB? ) and the pink BB's over the X Axis projection ( resulting in a overlap ), and then proceeds to which-ever detailed Collision method was originally requested. Similar to the current 2D_OBB implementation, although that one is limited to the Z-Axis only. Correct?

And what about 2 Boxes that are located in each other ( one smaller then the other ) that don't intersect? Does this situation return a collision in certain circumstances? Since ZGE does consider this a collision when using Box3D.

Finally ( this one is probably for Ville ), will the current ( non-OBB ) collision styles be preserved after a implementation of PAPPE?

K

[BeRo]

Luckily Mesh VS Mesh collisions are only needed under very few circumstances. Ray VS Mesh or Bounding Volume VS Mesh are more then sufficient in most situations, and a much smaller performance hit.

Yes, right.

By the way, ZGE features a Collision Group system enabling developers to limit the object combinations between Collision checks are executed. Does PAPPE support something similar to which this can be linked?

Yes and no, it depends on the view on it. PAPPE has for every object a CollisionSender and CollisionReciever property, but no groups, but this can be faked easy by multiple PAPPE instances.

Could you elaborate the purpose of the single Axis Sweep and Prune modes? My guess is that in the illustrated situation, when you use X-Axis S&P it uses the extends of the blue ( or does it use the white = non-matrix calculated BB? ) and the pink BB's over the X Axis projection ( resulting in a overlap ), and then proceeds to which-ever detailed Collision method was originally requested. Similar to the current 2D_OBB implementation, although that one is limited to the Z-Axis only. Correct?

Less or more yes. PAPPE would use here the white AABB and the pink AABB, and will do in a case of a overlap, if you've select a single-axis SAP mode instead the all-3-axis SAP mode, a BoundingSphere2BoundingSphere aftercheck. You can see the algorithm here at http://web.imrc.kist.re.kr/~jwkim/cours ... orithm.pdf how it works.

And what about 2 Boxes that are located in each other ( one smaller then the other ) that don't intersect? Does this situation return a collision in certain circumstances? Since ZGE does consider this a collision when using Box3D.

It's depends on the PAPPE object settings. Usually with the default object settings PAPPE doesn't report a collision then, because in PAPPE are box objects handled exactly like trimesh objects, but just for 6 quads / 12 tris, which is fast enough yet for my optimized trimesh2trimesh routines. Of course sphere objects will be handled by special sphere2sphere sphere2mesh routines and not handled by the trimesh2trimesh routines. This is also the sercet why PAPPE is so small in binary size, because I'm abusing some code parts for some other uses.

[VilleK]

Hehe sorry about calling it POPPE, I've edited the first post.

Finally ( this one is probably for Ville ), will the current ( non-OBB ) collision styles be preserved after a implementation of PAPPE?K

At this stage it is too early to tell, I've just begun thinking about this and created this thread so that you can be part of the decision process from the start. The zge collision-system is very fast and works for simple 2d-arcade games so maybe that mode should be kept also. The inclusion of PAPPE is likely to take some time and result in many intermittent beta-releases so that we can evaluate different approaches.

[BeRo]

I'll write new physics demos (for to demonstrate joints, constraints etc.) on this weekend probably.

Edit: http://bero.freqvibez.net/PhysicsDemo4.exe A small parameterunfinetuned rigid body constraint demo (is also on the SVN with source code). I'll write a rigid body joint demo later.

[VilleK]

Some more thoughts on this. As I said earlier this is currently just an investigation to see if we can fit PAPPE in ZGE in an meaningful, intuitive and efficient way. First we find out if it can be done, then we decide whether we want to include it or not.

If we go for the option to leave PAPPE unmodified then data must be synchronized.

First thing is the geometry of the model. Extracting all the triangles rendered by a zge model is difficult because of the design where a OnRender-list is a kind of "render-program" where logic components such as loops and conditions are allowed.

An easier option is to have separate properties on the model where you specify the geometry on which physics collisions will apply:

Model.UsePhysics True
Model.PhysicsGeoStyle (one of Mesh/Sphere/Cylinder)
Model.PhysicsGeoMesh (reference to a TMesh)

Second challenge is to synchronize the current transformation of the model. PAPPE operates on a transformation-matrix and ZGE use separate vectors for Position, Scale and Rotation.

So for each frame, for every model with UsePhysics=True:

update physics transformation based on Position, Scale and Rotation
call physics update for this model
update Position, Scale and Rotation with results from physics transformation

This seems terribly inefficient, can anyone think of a better way?

[kattle87]

If we go for the option to leave PAPPE unmodified then data must be synchronized.

First thing is the geometry of the model. Extracting all the triangles rendered by a zge model is difficult because of the design where a OnRender-list is a kind of "render-program" where logic components such as loops and conditions are allowed.

This is what I would do: Physics checkbox/dropbox in the model in which you choose what physics model to use, and if needed another dropbox in which you ARE ASKED a SINGLE MESH to be used for physics. It should do a copy of the triangles every time the mesh is refreshed but this should be trivial.
Most of the time, you will just give it the same mesh you are using for rendering, other times, you will find a simpler mesh/another model that fits your needs. This way it should be powerfull yet usable.

[jph_wacheski]

humm,. not sure about the Transformation-Matrix vs separate vectors stuff,. is a transformation-matrix more efficient,. perhaps ZGE should adopt this? major rewrite issues aside,. just an intelectual question on speed and engine architecture out of curiosity.

Model.UsePhysics True
Model.PhysicsGeoStyle (one of Mesh/Sphere/Cylinder)
Model.PhysicsGeoMesh (reference to a TMesh)

this seems right to me.

perhaps even Mesh/Sphere/POINT/Cylinder/CUBE for further simplification,. if PAPPE could gain anything from those simpler models,. . suppose a point is a sphere with no distance checking and a cube could be a very simple cylinder,. . whatever.

when UsePhysics is True will the model not get its Collision from the physics engine? perhaps physics should be on the CollisionStyle pulldown? then CollisionBounds/offset could be taken for PAPPE to use as well,. does it not use a cube first or is that created on the fly from the mesh?

oh well just 'input' from a guy to dumb (frightened!) to read the source code,. .