Bullet physics?

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

Post Reply
Posts: 58
Joined: Sun Sep 09, 2012 7:59 pm

Bullet physics?

Post by darkhog » Mon Sep 10, 2012 5:53 am

It would be helpful to be able to use Bullet Physics in our games. This will be useful for realistic projectile trajectory, easy making things that currently requires quirky ZExpression math magic, etc.

In Bullet component we would set such things like mass, air resistance, collision bounds (static triangle, convex hull,etc) and other things that can be used for objects in Bullet.

In BulletWorld we would set gravity. Such BulletWorld component will be then attached to Bullet component. If Bullet component has no BulletWorld attached, it is assumed that it has 0 gravity in all directions.

//edit: Found out about ZGEBullet, but I'd like more integrated solution, i.e. inside software instead of separate DLL.

User avatar
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Mon Sep 10, 2012 12:19 pm

I'm not a developer of ZGE, but I think there are several reasons why not to integrate Bullet with ZGE at the level of source code, i.e., to provide special components and functions:

1. Smaller ZGE executables. One of the intentions was to create small (64kB?) executables of ZGE applications. Integration of Bullet to the ZGE engine would extend its size. In addition, not all application use physics, so Bullet would be useless for them.

2. Complexity of Bullet. Bullet has a lot of classes (data structures), properties, functions, etc. Corresponding ZGE components and functions would probably be very complex to achieve satisfactory functionality of Bullet simulation. I'm not telling you it's impossible, but would be quite challenging and will take longer to implement.

3. More flexible updates of Bullet support. Updating ZGEBullet, by new versions of Bullet, fixing bugs, and extending functionality is much more simpler and faster than updating ZGE components and functions.

4. Development of ZGE should be kept independent to development of Bullet. For instance, if some bugs appear in Bullet, ZGE should not wait for their fixing.

5. Simpler development of ZGE. I'm not a Pascal programmer, but integration of Pascal with C++ probably comes with some overhead. ZGE distribution would come with different versions of the Bullet library for each supported operating system, etc. Building of ZGE should probably include also building of Bullet wrappers, etc.

darkhog - I agree with you that having a good integrated physics would be much convenient for users, however, much complicated for development of ZGE.

Note: After several ZGE projects incorporating physics, I must say that ZGEBullet is not such a pain and using it in ZGE scripting is very flexible. After 2+ year experience with ZGE, I prefer scripting to components anyway.

Posts: 58
Joined: Sun Sep 09, 2012 7:59 pm

Post by darkhog » Mon Sep 10, 2012 12:38 pm

1. ZGE could have two runtimes, one with bullet and one without. Then in App's properties, there would be checkbox, like "Use Bullet Physics" that if checked would export using bullet-enabled runtime. That would take care of size if bullet is not needed. Of course real-time stripping of code would be better, but also harder to do.

2. True, but using ZGEBullet from game/app developer's standpoint is royal PITA. I've downloaded demo app available on Google Code, but it is so complicated that I wasn't able to comprehend true form of it.
And Bullet usage from game dev's standpoint doesn't have to be hard. Just look at Blender Game Engine and JMonkeyEngine - those two engines did it right way.
You may ask why I'm not using BGE/JME instead. Well, my goal here is to expand my abilities and learn. You see, BGE/JME became to easy for me and I want a challenge. But not such hard challenge.

3. If current Bullet lib version works, it isn't required to update it unless it brings some major updates, like new collision shapes.

4 See 3.

5. That's true, but it is already integrated. Via ZExternalLibrary. It is matter of hardcoding calls that make it work with ZExternalLibrary plus adding components (which would be inaccessible if "Use bullet physics" checkbox mentioned in 1 would be unchecked).

User avatar
Site Admin
Posts: 2052
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden

Post by VilleK » Mon Sep 10, 2012 3:47 pm

The problem with multiple runtime is that they take time to build and maintain. We already have a bunch of runtimes:
1. Win32 normal
2. Win32 screensaver
3. Android
4. Linux
5. Mac OS X

So if we were to have optional bullet physics built-in we would need to double that number. It is already a problem with Linux and Mac because I no longer have up to date build environments for them.

If ZGE was an commercial product someone could be responsible for setting up build environments and automate build for every release, but since that is pretty time consuming and boring work I expect noone to volunteer to do that for free.

And combining Pascal and C in same binary is problematic. It would work better with BeRo Pascal based PAPPE engine that we tried earlier (there is a separate branch in Svn for it). But I think Rado1's library solution is excellent.

Creating small independent binaries is a difficult task. ZGE is build around this goal and using it will make it easier but it still never will be as easy to use as the other tools that don't care about executable sizes.

User avatar
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Tue Sep 11, 2012 9:50 pm

darkhog wrote:but using ZGEBullet from game/app developer's standpoint is royal PITA. I've downloaded demo app available on Google Code, but it is so complicated that I wasn't able to comprehend true form of it.
... hmmm... using of ZGEBullet is relatively simple if you understand principles of Bullet. The demo you tried to understand provides a generic framework for Bullet simulations/demos in ZGE, so it is complicated for newcomers.

If you want to use ZGEBullet, in your application, follow these quite straightforward rules:

OnLoaded section:
1. Include ZGEBullet external library in your project.
2. Initialize the bullet world by zbtCreateWorld() and optionally also set gravity with zbtSetWorldGravity().
3. Create and remember collision shapes you will use in your application by means of zbtCreate*Shape functions. It is recommended to create shapes shared by several physical objects (called rigid bodies) just once; e.g., to create a shape of cube used by many cubes placed to a simulated scene.

OnClose section: just destroy the physical world and all defined collision shapes by zbtDestroyWorld() and zbtDeleteAllShapes().

OnUpdate section: perform the Bullet simulation step (ZGEBullet uses discrete simulation) by delta time from the last rendering (ZApplication.DeltaTime), use zbtStepSimulation(). This will update positions and rotations of all objects in the scene based on their physical properties and current state.

To put physics-aware objects to the scene, you must create rigid bodies by means of zbtAddRigidBody() function. They correspond either to objects in environment (usually static, such as walls, ground) or objects represented by ZGE models (usually used for dynamically moving objects). Statical objects have mass 0, for dynamic objects mass is more than 0. Each rigid body specifies its shape by a reference to one of the previously created collision shapes.

Scene initialization (can be, e.g., part of OnLoaded section or OnStart section of an AppState component):
1. create rigid bodies corresponding to the scene's statical objects.
2. Spawn models used to represent dynamic objects. BTW they can be spawn any time during simulation.

Physics-aware model:
1. Define as local variable used to remember the model's rigid body.
2. OnSpawn section: create rigid body and optionally also set some additional (advanced) physical properties, such as damping or deactivation threshold.
3. OnUpdate section: update position and rotationof the model by: zbtGetPosition(BrickId, CurrentModel.Position.X, CurrentModel.Position.Y, CurrentModel.Position.Z); zbtGetRotation(BrickId, CurrentModel.Rotation.X, CurrentModel.Rotation.Y, CurrentModel.Rotation.Z);
4. OnRemove section: remove rigid body by zbtDeleteRigidBody().

Remark: The rendered shape of the model should of course correspond to the used collision shape.

And that's all. Can look complicated at the first look, but actually it is not when you try it in your own example(s). And of course, I could answer you any questions if you decided to use/try ZGEBullet.

Attached you will find a much simpler example I used for initial testing of ZGEBullet for Android.
Simple example of ZGEBullet
(1.6 KiB) Downloaded 167 times

Post Reply