Spheres do not collide properly

[alphama1e]

Keep in mind, I've just started using this engine over the last coupe weeks. I'm also new to XNA. I'm a student and have only been using it this semester. With that here's my problem. I've been working on a billiards game using XNA, Bepu and sample code from the basic demo provided by Bepu and from a windows management sample allowing me to use a screen manager. I've gotten to the point where I can drop a ball on the table. I'm using the shooting code to shoot more balls at the original. The balls I shoot fall through the table. When I make contact with the original ball, it too falls through the table. When I move to the floor and shoot balls at each other, I notice that they don't collide right either. The edge collision doesn't trigger and they roll through each other. The point where they do collide is when an edge of one object makes contact with the origin of another. I know I'm doing something really wrong but I don't know what it is. The worst part is I'm getting a little pressured and desperate because I have to get something working by today so other group members can work further on this project. Keeping in mind of how new I am, where am I going wrong? What can I do to fix the collision? I don't need someone to do the work for me but I at least need some class references from the .chm file to look at. A little logic advice wouldn't hurt either. Any help is appreciated. Thanks.


For reference I've included the link to my project:

https://rapidshare.com/files/842963271/9Ball.rar

unfortunately, it's too big to upload to the forum itself.

[Norbo]

It appears that the graphic of the balls is substantially larger than the ball shape. So, when two balls come near, you see the graphics overlap way before any collision takes place. That's also why you see the ball graphics sinking into the ground and why the graphic seems to rotate far faster than the linear motion would seem to require.

Additionally, the table's physical representation is a 1x1x1 box. The first ball falls right on top of it. Hitting the first ball knocks it off that tiny box, making it fall. Other balls fall through because there is nothing there, unless you aim right at that 1x1x1 box.

It may help to try setting up a prototype simulation up in the BEPUphysicsDemos project first so that you can see the objects with the BEPUphysicsDrawer easily. You can also include the BEPUphysicsDrawer in your own project for debug visualization purposes if you'd like.

[alphama1e]

Thanks for replying. I took a look at the simulation demo. It looks pretty cool. As I'm playing with different table sizes and scales, where should I look to read about drawing bounding boxes and bounding spheres for the bumpers and pockets? That's the next step I need to take but I don't know the best approaches and necessary classes to draw them. Thanks again for the help. I'll probably come back from time to time today with more questions. I'm gonna be in front of my laptop for a long time until I get this done.

edit - also, to what scale are space units? 1 unit to 1 foot or 1 meter? Thanks.

[Norbo]

where should I look to read about drawing bounding boxes and bounding spheres for the bumpers and pockets?

The BEPUphysicsDrawer project contains a helper class for drawing the bounding boxes of entities in a space (BoundingBoxDrawer), but that's about it as far as drawing bounding shapes goes.

If you want to visualize physics entities, as opposed to just their bounding boxes, then you'll need the ModelDrawer. It's pretty simple to set up and use; create a ModelDrawer (instanced or brute), add stuff to it, call the Update method in your update method, call the Draw method in your draw method. The BEPUphysicsDemos uses it, though you might have an easier time examining it in one of the simpler isolated documentation demos like the multithreading demo (linked here).

The engine itself is conceptually separated from graphics, so there's not much else.

[Norbo]

edit - also, to what scale are space units? 1 unit to 1 foot or 1 meter? Thanks.

The engine does not assume any particular unit. It's up to the user to assign meaning to the values. If a gravity of (0, -9.81f, 0) is used with the intention of simulating earthlike gravity, that implies a unit is interpreted as a meter and time units are seconds.

However, while the engine doesn't care about what you call the units, it does care about the actual values you use. For example:
-There are some default tuning factors which make the engine prefer individual objects with sizes between 0.5 and 10 units. It can handle sizes significantly beyond that, but staying in that rough range helps guarantee stability. These can be adjusted (see the BEPUphysicsDemos ConfigurationHelper.ApplyScale method and the ScaleDemo).
-Using huge or extremely tiny masses can interfere with some other minimum impulse tuning factors. This can cause performance or quality to suffer a bit in the most extreme cases.
-Single precision floating point numbers cannot represent all real values. As you get further and further from 0, values become more and more sparse. One possible way to introduce a failure through this: deciding to position the simulation out at (99999999999999, 0, 0).