KR is the "coefficient of restitution" which determines how "bouncy" a surface is. 1.0 means very bouncy (no loss), and 0.0 makes things get stuck on contact (vertical).
Let me illustrate Homer's point,
We have 2 objects A and B. Let's call the initial speed of A be Ua and that of B be Ub and the speed of A and B after collision be Va and Vb.
Then,
Va - Vb = -e(Ua - Ub)
Where e is the coefficient of resitutition.
Basically what I was eluding to in my last post was the following:
where we wish to calculate the instersection of a sphere and a plane, we should "offset the Plane along its SurfaceNormal by the distance of the SphereRadius, then calculate the intersection of the ray between the Sphere's Old and New origin positions".
We are using a ray based on the sphere origin at two locations, but we are testing it against a theoretical surface which is offset from the actual surface. This gives us an intersection point ON THE THEORETICAL SURFACE which is exactly "radius" from the actual surface, which is the same as saying "find the intersection of the sphere boundary and the plane", and gives us the exact coordinates to move our sphere to.
The response vector can be calculated on the theoretical intersection, and immediately applied to the sphere's center of mass (origin).
I'm a bit miffed that nobody has offered to look into my math to see what was wrong, so I'm going to take a slightly different tack.
I'm going to apply a virtual Sphere to the Camera, so that I have a sphere which can be controlled by the user. Then I'm going to collide it with the world surfaces such that the camera may not penetrate them.
This was going to be my next port of call, so I'm merely rearranging my priorities a little. Once I have working "camerasphere collisions" then arbitrary sphere collisions are a piece of cake.
I'm seriously considering turning this into a "RunTime CSG Editor" (CSG=Constructive Solid Geometry), whereby you fly around the virtual world, adding and modifying the geometry in full 3D.
Would anyone be interested in such a project?
where we wish to calculate the instersection of a sphere and a plane, we should "offset the Plane along its SurfaceNormal by the distance of the SphereRadius, then calculate the intersection of the ray between the Sphere's Old and New origin positions".
We are using a ray based on the sphere origin at two locations, but we are testing it against a theoretical surface which is offset from the actual surface. This gives us an intersection point ON THE THEORETICAL SURFACE which is exactly "radius" from the actual surface, which is the same as saying "find the intersection of the sphere boundary and the plane", and gives us the exact coordinates to move our sphere to.
The response vector can be calculated on the theoretical intersection, and immediately applied to the sphere's center of mass (origin).
I'm a bit miffed that nobody has offered to look into my math to see what was wrong, so I'm going to take a slightly different tack.
I'm going to apply a virtual Sphere to the Camera, so that I have a sphere which can be controlled by the user. Then I'm going to collide it with the world surfaces such that the camera may not penetrate them.
This was going to be my next port of call, so I'm merely rearranging my priorities a little. Once I have working "camerasphere collisions" then arbitrary sphere collisions are a piece of cake.
I'm seriously considering turning this into a "RunTime CSG Editor" (CSG=Constructive Solid Geometry), whereby you fly around the virtual world, adding and modifying the geometry in full 3D.
Would anyone be interested in such a project?