源地址：http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Hello_World
注：<bullet>表示bullet安装目录。
1、配置VS。
工程属性->C/C++->附加包含目录：<bullet>/src
工程属性->链接器->附加库目录：<bullet>/out/release8/libs
工程属性->链接器->输入->附加依赖项：libbulletcollision.lib libbulletdynamics.lib libbulletmath.lib
2、HelloWorld。
3、解析。
Creating The World
Now, we will add a Bullet simulation. First, an appropriate include:
We want to instantiate a btDiscreteDynamicsWorld but to do this we need some other things too. For a "hello world" example they are cumbersome because we don't need them. However, as we mature our software into a useful product, they will be useful for fine-tuning the simulation.
We need to specify what Broadphase algorithm we want to use. Choosing the broadphase is important if the world will have a lot of rigid bodies in it, since it has to somehow check every pair which when implemented naively is an O(n^2) problem.
The broadphase uses conservative approximations of object shapes, and these are called proxies. We need to tell Bullet the maximum number of proxies that we will use, so it can size arrays without wasting memory. This is the maximum number of rigid bodies that can be in the world at any one time.
Some broadphases use spatial datastructures that require the world size to be known in advance, as in our case here. The broadphase may start to malfunction badly if objects leave this volume. Because the AxisSweep broadphase quantizes space based on the size of the entire space we're using, you want to make this roughly the size of your world.
Making it smaller than your world will lead to major issues, making it larger than your world will lead to inferior performance. This is one of the simplest parts of your program to tweak, so it's worth taking the time to make sure your numbers are correct. In this example, the world extends 10 kilometers in every direction from the origin.
This is the broadphase we will be using, it is an implementation of Sweep and Prune, explained on the Broadphase page.
The broadphase is an excellent place for eliminating object pairs that should not collide. This can be for performance or gameplay reasons. You can use the collision dispatcher to register a callback that filters overlapping broadphase proxies so that the collisions are not processed by the rest of the system. More information in Collision Things .
The collision configuration allows you to fine tune the algorithms used for the full (not broadphase) collision detection. Here be dragons!
We also need a "solver". This is what causes the objects to interact properly, taking into account gravity, game logic supplied forces, collisions, and hinge constraints. It does a good job as long as you don't push it to extremes, and is one of the bottlenecks in any high performance simulation. There are parallel versions available for some threading models.
Now, we can finally instantiate the dynamics world:
One last (rather obvious) line sets the gravity. We have chosen the Y axis to be "up".
Bullet has a policy of "whoever allocates, also deletes" memory, so all of these structures must be deleted at the end of main().
We now have prepared the first few lines that are common to *any* Bullet application. The code up to this point looks like this:
Collision Shapes
We will create a ground plane [a static rigid body], and a sphere that will fall onto the ground [a dynamic rigid body]. Each rigid body needs to reference a collision shape. The collision shape is for collisions only, and thus has no concept of mass, inertia, restitution, etc. If you have many bodies that use the same collision shape [eg every spaceship in your simulation is a 5-unit-radius sphere], it is good practice to have only one Bullet collision shape, and share it among all those bodies. However, we only have two rigid bodies and they are not the same shape so they will need a shape each.
In this demonstration, we will place a ground plane running through the origin. For pedantic purposes, we will define the collision shape with an offset of 1 unit from the origin. Later, we will place a rigid body using this shape in the world -1 unit away from the origin so the two offsets cancel and the plane winds up intersecting the origin. You could just use 0 for both values and achieve the same result, but here we place a plane defined by y = 1:
The shape that we will let fall from the sky is a sphere with a radius of 1 metre.
Collision shapes must be deleted at the end of the show just like everything else.
Rigid Bodies
Now we can add the collision shapes into our scene, positioning them with rigid body instances.
Lets first instantiate the ground. Its orientation is the identity, Bullet quaternions are specified in x,y,z,w form. The position is 1 metre below the ground, which compensates the 1m offset we had to put into the shape itself. Motionstates are covered in detail on a page dedicated to them: MotionStates
The first and last parameters of the following constructor are the mass and inertia of the ground. Since the ground is static, we represent this by filling these values with zeros. Bullet considers passing a mass of zero equivalent to making a body with infinite mass - it is immovable.
Finally, we add the ground to the world:
Adding the falling sphere is very similar. We will place it 50m above the ground.
Since it's dynamic we will give it a mass of 1kg. I can't remember how to calculate the inertia of a sphere, but that doesn't matter because Bullet provides a utility function:
Now we can construct the rigid body just like before, and add it to the world:
A quick explanation of btRigidBody::btRigidBodyConstructionInfo is in order; when bodies are constructed, they are passed certain parameters. This is done through a special structure Bullet provides for this. The components of the btRigidBodyConstructionInfo are copied into the body when you construct it, and only used at initialisation time. If you want to create a thousand bodies with exactly the same properties, you only need to build one btRigidBodyConstructionInfo, and pass that same one to all the bodies that you create.
Stepping The Simulation
This is where the fun begins. We will step the simulation 200 times, at an interval of 60hz. This will give the sphere enough time to hit the ground under the influence of gravity. Each step, we will print out its height above the ground.
The stepSimulation function does what you'd expect, but its interface is fairly complicated. Read Stepping The World for more details.
After stepping, we examine the state of the falling sphere. The position and orientation are encapsulated in the btTranform object, which we extract from the falling sphere's motion state. We are only interested in the position, which we pull out of the transform with getOrigin(). We then print the y component of the position vector.
This should yield an output that looks like this:
sphere height : 49.9917
sphere height : 49.9833
sphere height : 49.9722
sphere height : 49.9583
sphere height : 49.9417
sphere height : 49.9222
sphere height : 49.9
...
sphere height : 1
sphere height : 1
sphere height : 1
sphere height : 1
sphere height : 1
Looks good so far. If you graph this output against the number of iterations, you get this:
The sphere comes to rest 1 metre above the ground. This is because the position is taken from the centre of the sphere and it has a radius of 1 metre. The sharp-eyed will note that the sphere penetrates the ground slightly before bouncing and coming to rest. This is to be expected in realtime physics engines, but it can be minimised by increasing the frequency of the simulation steps. Try it and see!
Now you can integrate the dynamics world into your application and render falling spheres. Check out the other Collision Shapes as well. Try stacking boxes or cylinders and then shooting them over with spheres.
kenshin的中文翻译：http://hi.baidu.com/kenshin1987/blog/item/9fe00afb8134878f9f51468c.html
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
