244 replies to this topic

[andbna]

The Bullet Physics library is a 3D physics engine which is not only completely open source, but is also used in several commercial applications, including on consols such as the PS3. The project is lead by Erwin Coumans, and the homepage can be found at http://www.bulletphysics.com/

This DLL allows GM users to take advantage of this powerfull library.

Current features supported by the DLL:
-Discrete (non-continuous) simulation
-Rigidbodies
-Constraints
-Concave/convex triangle meshes
-3DS and BSP file loading
-.obj, .x, and GM model file loading with GMModelEx.
-Raycasting
-D3D based Debug drawer
-Vehicle constraint
-Data structure based Get/Set functions, for rapid communication.

Last updated: April 12th 2009. Most recent version: 1.34

The DLL and extension package can be downloaded at: http://www.andrewpaul.com/GMBullet.zip
A Help file is included, please use it.
Source code included.

If you find any bugs, please post reports in this thread. Please include a description of the bug, how to re-create it (ie: what causes it?) And, if possible, an editable game file which demonstrates the bug.

New feature and function requests are also welcome

---

Continuing from the Request topic:
A bug was found in the get_rotation functions, it has been fixed, the rotations should work correctly now.
The problem was 2-fold. First, Bullet uses a left-handed coordinate system instead of a right-handed one, thus all rotations were being performed in the wrong direction (that took a while to figure out,) and second, it seems Bullet's internal matrix-to-euler conversion is not working with GM correctly, and has been replaced with other code. The Zip file has been updated with the new version.

The new Euler rotations need to be applied in the order: y,z,x as opposed to x,y,z.
Also note that I added code to negate the input angle values from the various functions which define rotations (to convert counter-clockwise rotation to clockwise.) If this is in err, let me know.

-Andrew

Edited by andbna, 12 April 2009 - 04:47 AM.

[hanson]

Great work so far! I would suggest though that you return the rotations from the dll in such a way that the transformations are applied in xyz order. This is as simple swapping the code in the dll functions. Pretty simple, but it would make it easier(for me) to use .

-hanson

[Rixeno]

Yes, the rotations are fixed, this is great! So now I can go back at the example (which I accidentally deleted with the old version)... oh well, I'll just start back, it shouldn't take long, I'll try to get something going on soon

EDIT: Thanks gosh that I uploaded it on BOX.net, nevermind, I didn't lose the example, I'll try to restart the example

Edited by Rixeno, 06 June 2008 - 09:41 PM.

[Rixeno]

I'm still getting problems with my old example with rotations, it's just the coding, so I'll restart a new one. I'm surprised there isn't many comments about this considering people have been asking for 3D physics DLLs for ever

[andbna]

Hanson; sorry changing the rotation order is a bit more mathematical than changing a few things around, but I'l look for some code designed for an x-y-z order (or derrive it myself if I have to... maby thats what French class will consist of tomorow )

Thanks Rixeno for continuing to work on that example, give me a shout if those rotation problems persist!

Anyway, I'm continuing to add features to the DLL, currently I'm working on ray and convex sweep tests, as well as collision masks and 'collision at position' functions.

-Andrew

[hanson]

Oops - you're right. I thought you meant something different. It makes more sense now that I read it again

-hanson

[Rixeno]

Cool, more features. Exams are coming up this week and next week, so I'll be busy on others things for quite a while, I'll try to find time here and there anyways

EDIT: I'm currently having an error, I don't know if I missed something, but the rotations didn't change for me... HERE'S the link of the file so far (it's still the old version that I last updated last month with small updates...)

Edited by Rixeno, 09 June 2008 - 10:57 PM.

[andbna]

Rixeno; the rotations are in the wrong order, you now have to apply them in:
Y
Z
X

Sorry about the confusion, I will get it back to X-Y-Z soon.
-Andrew

[Rixeno]

lol, I finally found out what that meant, I had to call the rotations in that order... No problem , I tried it again and it worked flawlessly, I might get an example done before the end of the month (because exams next week)

EDIT: This is what I have so far, you can add it to the download if you want Andbna, but I plan on using more of the functions later on after the exams next week maybe. I think this is the link : DOWNLOAD

Edited by Rixeno, 11 June 2008 - 08:02 PM.

[luenardi]

This Rules!

[icuurd12b42]

I'm real happy someone took over this task. When someone suggested it, I took a look at the API and found it way over my head.

I bumped the room speed to 60. Unfortunatly, at 50 cubes, the FPS is 30. The slowdowns is due to the number of APIs call needed to map the GM objects to the world objects.

You can fix that by packing the x,y,x,rx,ry,rz into one value and unpack it in gm... Someone made an example on how to do that that in the comunity. That would reduce the number of dll calls by 6

Make the cube invisible and comment out the step event, you will get more instances.

Unfortunatly, the FPS really starts to drop around 60 cubes now. While the new cube is moving the fps drops to 25. Then it's back up to 60 when the new cube stops moving. That must be in the simulation itself. There has to be something there that was overlooked.


I'd be happy to go through the code if you want.


Take care!

Edited by icuurd12b42, 14 June 2008 - 08:10 AM.

[Rixeno]

It's also true that D3D isn't the fastest method for 3D, I'd like to create a U3D demo once I get the D3D demo finished and compare the speed results (which I think I can already tell...)

NOTE: I just finished two exams yesterday, I have 3 more to go until I restart working on the example

[icuurd12b42]

It's also true that D3D isn't the fastest method for 3D, I'd like to create a U3D demo once I get the D3D demo finished and compare the speed results (which I think I can already tell...)

NOTE: I just finished two exams yesterday, I have 3 more to go until I restart working on the example

Yeah, I know, that's why I disabled it to only test the DLL.


You need to be aware that you have a limit of 100-200 dll calls per step... Even less if you try to run at 60 FPS.

[andbna]

Thank's for your feedback luenardi and icuurd

The slowdowns is due to the number of APIs call needed to map the GM objects to the world objects.
You can fix that by packing the x,y,x,rx,ry,rz into one value and unpack it in gm... Someone made an example on how to do that that in the comunity. That would reduce the number of dll calls by 6

I'd been wondering about whether that would be a problem. Thanks for stress-test.

Now, as for the slowdown with the cubes; it's actualy not going as slow as you think. I had a chance to better look through Rixeno's example, and the StepSimulationCall is a bit iffy.

gmbStepSimulationTime(10,room_speed/2,0.005);

The first argument is the amount of time (in seconds) that you want to simulate for during that single call (ie: time elapsed since the last call.) The third argument is the internal framerate of the DLL (ie, number of simulations you want it to do per second.) The middle is a frame-cap for a single call.
0.005 is a frame-rate of 200Hz, and 10 seconds at 200FPS, means 2000 simulations per call! Of course, the frame cap of room_speed over 2 limits this amount to 15 simulations from that 1 function call at a roomspeed of 30.
Now, multiply this by the 30FPS GM is running at, and you get 15*30=450FPS that the DLL is running at.

Jack up the room speed, and you increase the frame-rate cap to 60/2=30, but you also try and call the step simulation twice as much, so at a room speed of 60, your demanding Bullet to do 30FPS*60FPS=1800FPS. That's some pretty hardcore simulation.

However, the actual speed of the game is 25FPS you said, so multiply that by the 30 frames Bullet is running, and we get 25FPS*30FPS=750FPS that Bullet is able to simulate at. Not bad considering it's standard frequency is 60FPS.

To correct the step simulation call, try something allong these lines:

gmbStepSimulationTime(1/room_speed,1,1/room_speed);

Now I'v asked Bullet to keep it's internal frequency equal to GM's. I'v also asked it to perform 1/room_speed amount of simulation, so it should do 1 simulation for each StepSimulation call. Since as it is set up there it will always execute 1 simulation per call, I capped the max number of steps at 1; it really dosnt matter.

One might consider however using Yourself's High Resolution Timer, and actualy computing the time difference between the current and the last call, allowing for a variable framerate game, while keeping a fixed framerate physics simulation (Bullet will also interpolate for you if you ask it to simulate less time than it's frequency.)

Anyway, the only other thing is, you don't need to create the same cube/cyllinder/sphere shape each time you create a corresponding RigidBody. But that should not really affect simulation. It's looking great Rixeno, and good luck with your exams.

-Andrew

Edited by andbna, 14 June 2008 - 03:30 PM.

[icuurd12b42]

It sure is a thing of beauty to watch... Though with the new setting, it's all slow motion.

So I set the room to 60 and kept adding cubes until the fps was 30. Giving me the maximums (for a 30 FPS game).

200 instance with draw
320 with no draw
1600 with not update calls
800 instance with single udate get data and unpacking the values

You could move the gm synch position to the draw event so that when we hide the instance it no longer updates

For unpacking, I assume the first 3 bytes would be 360 degrees packed in a 0 to 256 byte

the remainding bytes can be used to pack the x,y,z. Not sure how much you would loose in room size or granularity though


All you need is supplement your API by adding the extra "one call gets all" function for the hard core guys and suply a GM unpacking routince

packet = gmbGetPositionPacket(body);

rotx = packet & $FF/255*360
roty = packet >> <2bytes> & $FF/255*360
rotz = packet >> <4bytes> & $FF/255*360
and so on


I'm pretty sure I'm going to use this in a 2d top down space game. I was making a dll for the collision/rotation/momentum system but this does what I was coding. AND IT WORKS UNDER VISTA AND GM7. Yes!

You dont really need Yourself's dll, GM's date/time functions (not the current_time) go all the way down to 1 millisec wich is good enough for game timing..


Check this method to reduce API calls too
http://gmc.yoyogames...&...t&p=2734336

Edited by icuurd12b42, 14 June 2008 - 08:28 PM.

[andbna]

Though with the new setting, it's all slow motion.

Yah, it appears that way since there is no real perspective to base the speed and distance on other than the camera's distance from the floor, which one assumes to be about 1.5m (looking through a persons eye's). Relative to the gravity however (assuming we are on earth), it's more like 10meters. Those cubes are ~15m in length, and that floor your standing on is nearly half a kilometer squared, so they are falling from quite a distance above. Set the gravity to around 100 and it should look more 'normal.'

Thanks for those numbers too; those are pretty nice results Good to hear it works on Vista too.
I'l certainly add some One-call-update functions for the next update, thanks for that link.

And good to hear this is gonna be put to use already Good luck with the space game.
-Andrew

[icuurd12b42]

Though with the new setting, it's all slow motion.

Yah, it appears that way since there is no real perspective to base the speed and distance on other than the camera's distance from the floor, which one assumes to be about 1.5m (looking through a persons eye's). Relative to the gravity however (assuming we are on earth), it's more like 10meters. Those cubes are ~15m in length, and that floor your standing on is nearly half a kilometer squared, so they are falling from quite a distance above. Set the gravity to around 100 and it should look more 'normal.'

Thanks for those numbers too; those are pretty nice results Good to hear it works on Vista too.
I'l certainly add some One-call-update functions for the next update, thanks for that link.

And good to hear this is gonna be put to use already Good luck with the space game.
-Andrew

Cool

Bug
global.GMBULLET_GMBULLET_ActivateBody = external_define('GMBullet.DLL','GMBULLET_ActivateBody',dll_cdecl,ty_real,2,ty_real,ty_real);


Are all the functions implemented? Or are some of them stubs... Because the only thing working (for me so far) is the world gravity. I can't seem to be able to add momentum manually to the objects using
Set/AddLinearVelocity...


I merged with my space game, thought the bullets are not "GMBulletized" yet, A added a collision with the cubes, and tries to add momentum to the cubes when the bullet hits... Maybe the values are too small. Though gravity s off and so is friction (I assume)

[edit]
Nevermind. I figured it out. I was activating the body on create... It got deactivated because it's not moving (I Guess). So my motion calls had no effect.

Tip: Move the function in the API... One less function to call.
Tip2: Give my angles in degrees (Add to the API, keep the original), one less GM interpretation line to do/ Lets squeeze as much juice out of it as we can...
[/edit]

So the values are meters... Good to know.


Perhaps you can add a setWorldScale. Similar to FMOD sound system.

[code=auto:0]
//export double FMODSetWorldScale(double scale)
//Sets the scale of the worls.
//Default scale is 1 meter per pixel
//it affects the doppler effect
//if your player moves 3 pixels in one second
//it will appear to the sound system as though he moved
//3 meters per second
//reduce the value to reduce the overall doppler effects in the game

return external_call(global.dll_FMODSetWorldScale,argumen
t0);
[/cdode]

In your case, it would affect speed and gravity

Edited by icuurd12b42, 15 June 2008 - 04:01 AM.

[andbna]

Bug
global.GMBULLET_GMBULLET_ActivateBody = external_define('GMBullet.DLL','GMBULLET_ActivateBody',dll_cdecl,ty_real,2,ty_real,ty_real);

Ah, the joys of copy and paste. Thank you, I'l fix the script.

Are all the functions implemented? Or are some of them stubs... Because the only thing working (for me so far) is the world gravity. I can't seem to be able to add momentum manually to the objects using
Set/AddLinearVelocity...

Yah, they are all implimented. Hmm, what type of object are you trying to add velocity too? Those particular functions only work with dynamic objects (type 1.) I think I tested those one's myself too, and found them to be working. Try Disabling deactivation when you create the bodies and try again, as a deactivated body won't respond to a manual momentum change (and Bullet handles deactivation for you.)

So the values are meters... Good to know.

The Bullet manual referances the units as meters, though I should think the actual unit does not really matter, other than sticking to something consistantly.

Perhaps you can add a setWorldScale. Similar to FMOD sound system.

Well, I would think that this is best implimented at the user-end, since scaling in those cases is a simple multiplication (I think the doppler effect uses a non-linear function,) and I don't think there would be any apreaciable speed difference between doing that in GM or in the DLL.

-Andrew

Edited by andbna, 15 June 2008 - 03:40 AM.

[icuurd12b42]

[edit-from post above in case you missed it]
Nevermind. I figured it out. I was activating the body on create... It got deactivated because it's not moving (I Guess). So my motion calls had no effect.

Tip: Move the function (Activate) in the API... One less function to call. If I'm adding motion, I want it active now.
Tip2: Give me angles in degrees (Add to the API, keep the original), one less GM interpretation line to do/ Lets squeeze as much juice out of it as we can...
[/edit]

But if the object was inactive, why does gravity affect it. Perhaps Inactive and static are not the same thing

Yes, well, in your case, the factor would only affect gravity I think. Where a gravity of 1 would resolve in a variable distance/sec relative to the world scale. but you are right, I can resolve this. But since I’m calling a dll, It's best to differ the math there too. Again, to squeeze as much out of this thing as possible.

OK, you have GetWHATEVERxyz but dont have a SetWHATEVERyzy, forcing me to call GetWATEVERx,y,z when setting only one value...

Like
gmbSetLinearVelocity(body, gmbGetLinearVelocityX(body),gmbGetLinearVelocityY(
body),0)


Normally, it's not an issue, but in GM it is. If you provide
gmbSetLinearVelocityY(body,<value>);
that would limit the damage. Not complaining here.


OK. I found a bug. Not wanting to be picky, but during the simulation, a level of error introduces itself which, over time, such as in the space game I playing with right now causes problems.

All my objects are a z 0, colliding at z 0 (center). But, the objects start to rotate on the x or y axis after a period of time and the z value changes sot object no longer collide since they are no longer on the same level. Which IMHO, should not happen. It's with cubes.

The little 3d demo allows adding hundreds of spheres on top of each other. They don't fall and that is fine because they are on the exact same x,y axis. I was expecting the same result with collision on the exact same zaxis.

Don’t want to be thorn on your side here. But you see how this can be useful in a top down setting for a 2d or 3d game you don’t want the z or xr,yr to change.


Ah, And I found a useful function you should add for a lite weight object

ApplyCollision(body,fmass,fx,fy,fz,fxr,fyr,fzr,fxs
,fys,fzs,otherproperties,...)

Effectively faking 2 objects colliding, but using a fake object as opposed to a real one (f)arguments. Where I supply where the fake object is located, its rotation, and speed/direction.

That way I can have, for example, a lot of bullets not affected by the world and having no step event acting out on a real world object. I simply use GM's collision event as a pre-check for collision and apply the collision in the system... Which may or may not result in a real collision in the system, depending if the fake object, given the setting, would actually collide with the real one. Hope the paragraph is clear enough.


Man I am so impressed right now.


Looks like I can make compound objects!?? Can you tell me how? It's the reason I was writing my own DLL. My setup involved adding/grouping a bunch of circles/spheres inside a sprite/model for collision and rotation based on impact position/rotation/direction/speed


Oh, and what shapes are most efficient in the system?


Ok, enough for now. There's always tomorrow.

[Hepolite]

I have to say that this is amazing! It might be just what I need, if only I could understand how to use it. i need some help with some models, a .3ds model.

The code I have now is:

gmbStartTriMeshShape();
gmbLoad3DS(working_directory+"\test.3ds");
shape=gmbFinishTriMeshShape(0);

But it don't work...
What would be the correct way for doing this?

Also, I'd like to see a description of what the script does inside GM, not just in the help-file. That would make this much easier to use.