# Add 'ground' to this physics system?

## Recommended Posts

Bounce Lite doesn't support only AABBs. It supports general convex hulls.

A convex hull can be represented by a half-edge based polygonal mesh. This representation is extremely important if you want to optimize SAT for fast queries.

Here how a convex hull is declared:

A box is a type of convex hull. Here's a compiled convex hull for a box:

The following file contains functions which uses SAT to test overlaps and generate contact points.

All the clipping code resides in this file:

Dirk gave a talk about the SAT back in 2013. This might get you introduced into this topic:

##### Share on other sites

The box hull actually lives here:

##### Share on other sites

how do I do without using hull?. I tried to understand your code I know you have given me a lot to work on. But I failed. My knowledge is not sufficient to understand your code. Now I doubt my skills. I attached a video of running my physics engine. It's weird.

##### Share on other sites

Simplifying the SAT and the contact creation code in Bounce Lite for two 3D OBBs is trivial.

For two OOBs the possible separation axes are the absolute face directions of both OOBs and their cross product.

You can get a more in depth explanation of the SAT for two OBBs in Christer's Real Time Collision Detection book, at page 101.

Again, in order to testing things out I would first implement a sphere on a plane. Then add more spheres. Then you can add more shapes to your engine.

If you have more questions regarding OBBs you should probably simple spin-off this topic into another thread for convenience.

##### Share on other sites
Posted (edited)

Edit: For two OBBs the possible separating axes are absolute local rotation vectors of the second OBB's frame expressed in the first OBB's frame and their cross product, not the absolute face directions.

Edited by Irlan Robson

##### Share on other sites
Posted (edited)
7 hours ago, Irlan Robson said:

Edit: For two OBBs the possible separating axes are absolute local rotation vectors of the second OBB's frame expressed in the first OBB's frame and their cross product, not the absolute face directions.﻿

This is neither correct nor helpful! As with every convex polyhedra the possible separating axis are the face normals and the edge cross products. Each OBB has three unique face and edge directions. The edge and face directions are the same in the case of the OBB. So there you need to test 6  face directions and 9 unique edge cross product directions for a total of 15 tests.

In a practical implementation it might make sense to transform the second OBB into the local space of the first one (or vice versa). The reason for this is that face and edge directions become the principal world axis (e.g. (1, 0, 0), (0,1, 0) and (0, 0, 1)). This optimizes and simplifies the implementation. I think this is more confusing than helpful in this discussion though.

As a side note, testing the possible separating axes is not the challenge here. Since you are only testing unique directions identifying the correct witness features for contact creation requires an extra step. E.g. Each face direction corresponds to two faces and each edge direction corresponds to four edges. You still need to figure out which faces or edges are actually realizing the contact.

23 minutes ago, Dirk Gregorius said:

Now I doubt my skills. I attached a video of running my physics engine

From the questions you are asking I can tell you that you have a very long way to go. The real question is what your goal is. If you are writing a game and implementing the physics engine is slowing you down you might want to consider using an existing solution. You will still learn plenty of things from there. If you are trying to learn how to write a physics engine this is indeed a good path and we are here to help.

Edited by Dirk Gregorius

##### Share on other sites
Posted (edited)

Yes, I know. Sorry, issu diss! Dirk is correct. I was just being extremely sloppy in my post.

For completeness, in general, we have the following pair of features which can build a separating axis. Achronyms for features: V = Vertex, E = Edge, F = Face.

FV/FE/FF, VF/EF/FF, EE, and VV.

Since VV only occurs if the shapes aren't actually penetrating, then you handle it in the FF case. FV/FE/VF/EF are handled by the FF case.

You can visualize the axis generated by a feature pair by drawing a line between the closest points between the features of two separated convex hulls .

You can find a good article on SAT in the book Game Physics Pearls.

After a quick search I found this beautiful implementation by my friend Randy for OBB-OBB overlapping test and contact generation which uses the rotations as axes:

Edited by Irlan Robson

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!