ZGameEditor forum

Hi guys,

What about when you just want to use the collision routines of PAPPE? Would you then leave the UsePhysics checkbox blank, while filling in the GeoStyle / GeoMesh slot?

One of my questions concerning physicalized models would be what PAPPE does when you overwrite the transformation matrix. Does it use separate values for velocity, or is it position / cache based? Which would probably mean that as soon as you input a new position, the collision check would use a trajectory you probably didn't intend to use.

Using matrices is always a little slower then just a bunch of parameters, but a more severe concern is whether or not PAPPE uses quarternions for rotations, since ZGE is completely Euler based.

K

jph_wacheski wrote: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.

Also I'm thinking this. But only the problem is that matrices are for newbies with weak math howto often too complicated.

jph_wacheski wrote: 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?

PAPPE can generate so such collision volumes from meshs automatically, but with some important rules in the matrix identity state body orientation, fot example at cylinders, capsules, etc.

Kjell wrote: One of my questions concerning physicalized models would be what PAPPE does when you overwrite the transformation matrix. Does it use separate values for velocity, or is it position / cache based? Which would probably mean that as soon as you input a new position, the collision check would use a trajectory you probably didn't intend to use.

PAPPE has a PhysicsObjectSetMatrix and PhysicsRigidBodySetMatrix (also PhysicsObjectSetVector and PhysicsRigidBodySetVector), where PAPPE updates also then the another internal values.

Kjell wrote: Using matrices is always a little slower then just a bunch of parameters, but a more severe concern is whether or not PAPPE uses quarternions for rotations, since ZGE is completely Euler based.

The speed depends also on the used math routines implementations, for example, whether it are SIMD (SSE/SSE2/SSE3/etc.) optimized or not, which these in PAPPE aren't not (yet).

Code to convert a 4x4 transform matrix to position+euler rotation in PAPPE:
Code to convert position+euler rotation to a 4x4 transform matrix in PAPPE:

Ok, here is what I will do:

First I make a new release of ZGE with the bug-fixes in the current beta. Then I'll begin with an attempt to use PAPPE in ZGE, and release a new beta of this as early as possible. Then we can continue the discussion and try different approaches. Since the ZGE-source is on a Subversion-repository we can always rollback and cancel the PAPPE-code later if it turns out it wasn't a good idea after all.

I've checked in the source for the first PAPPE integration in ZGE to the Subversion repository at a new branch called "pappephysics".

http://zgameeditor.googlecode.com/svn/b ... pephysics/

This means that the main build of ZGE is not affected and can be developed independently. We can continue to try out PAPPE whenever we have time and when/if we decide to use it we can include it in the main build or as a separate "ZGE Physics" release.

Ben has been very helpful and answered to my questions about the physics engine and made bugfixes and enhancements overnight. As he is now busy with other projects I think this is a good time to release what we got so far.

Here it is if you want to try it:

http://www.zgameeditor.org/files/ZGE_Physics.zip

A small demo-project is included. Please check it out to see how to use the PAPPE features.

Some notes:

- This is just a very minimum inclusion of PAPPE. Only Boxes and Spheres are supported, and there are many limitations on how to use them with ZGE-model components. The ZGE collision system has not been updated.

- The runtime binary have grown in size but is still way under the 64kb limit when compressed with kkrunchy.

- This is just a first test-release so be aware that everything about the physics implementation, including property names and values, can (and most likely will) change in a later release.

really, really nice! I hope the integration goes on, this is really looking promising =)

simply WOW !
Good job !
its so amazing ... Although somewhat buggy (small stacking stress test with 50 boxes = around 3 fps ), but looks promising ...
I will continue testing it ...

Yes this is quite cool,. I will play around with it and report back.

Just quickly started building a slightly prettier test area, attached. The third RMB press gives a 'pegged' cube to build solid structure stuff,.

Physics sims are netoriously fidgity and requite endless tuning to get usefull games from,. and this seems to be the case here as well,. time will tell.

Nice additions to the physics-project jph, I will use your version for future releases.

Sorry if this was answered somewhere else, but what happened to this idea? Sounds really cool!

Rather than to integrate a physics engine into ZGE it is probably better to call an existing engine like Box2D using a dll as we do in this thread.
That project is just begun though, it would be great to use more features from Box2D if someone is willing to look into it.

I'm assuming you lose crossplatformabilty with the dll calls?

Not really. There is currently only a precompiled binary of box2dzge.dll for Windows, but Box2D is available for a number of platforms so the same library could just as well be available there.

Calling external modules from ZGE works on all supported platforms, here you see an example of calling opengl from ZGE on Linux: viewtopic.php?t=528&postdays=0&postorder=asc&start=90

Wow! you've thought of everything