Our physics model is quite simplistic - theres no mass, no forces, no resistance, etc.. we only have velocity and position.
Nonetheless, our physics state values will be vital when it comes to responding correctly to a collision.

Like collision detection, collision response can be sophisticated or it can be simplistic.
Our immediate concern is that we can now detect collisions between spheres and bricks, and we want to implement a response in which the Sphere is deflected from the Brick, and the Brick is destroyed.
Herein lies the problem: our simplistic intersection detection thus far does not give us any information about the collision event, it only tells us that two entities collided and nothing more.
In order to make our ball bounce, we need to know which face of the  intersected brick was struck first, and we have no information.
This may seem quite an absurd situation at first glance, and when a sphere is moving very slowly, or the physics timestep is very small that is true... but for fast-moving entities, or larger physics timesteps, we need to be accurate.
I give the example of Quake3, where intersection tests are only performed 10 times per second, yet framerates may exceed 200 fps.

So, let's define the current problem as "which side of the brick was first intersected by the sphere?"
There's a number of ways one might approach this problem.
I've chosen to measure the distance from the Sphere to each of the Brick's 'Planes', along the straight line (ray) of the sphere's travel.
In other words, I'm going to cast a Ray at some Planes, measure the distance to any intersections along that ray, and choose the shortest distance.
Now we have determined which face was struck, we wish to calculate the reflected velocity of the sphere.
We'll use simplistic algorithm (they can be quite complex)
This algo is for a moving sphere and a fixed flat surface :)

N=Normal of surface
V=Sphere Velocity
K=Coefficient of Restitution ("bounciness")
R=Velocity after collision

Find R:
Q=(N DOT V) * N
T=V-Q
R=T-K*Q

That's it for the sphere.
Having calculated a new velocity for our sphere, we simply need to apply it to the sphere and let the simulation keep running.

The brick instance should be destroyed, and a little explosion effect of some kind should be displayed, and perhaps a sound effect? :)

Posted on 2006-08-08 00:46:35 by Homer

Will you be implementing some sort of particle effect when destroying the blocks?

Maelstrom
Posted on 2006-08-08 21:07:24 by Maelstrom
"a little explosion effect" - is done usually with particles, imho :) (though I wouldn't exactly call large animated textures with such a cute name :) )
Posted on 2006-08-08 21:45:43 by Ultrano
why not boundary prisms? the prisms extends in the direction of movement and could predict what face is hit first
extend it 2nd backwards with some semitransparent meshes and you get a nice effect, 3rd time in a 3rd direction and you can extract shadow volume outta it
Posted on 2006-08-09 03:19:03 by daydreamer
Regarding collision microtesting:
Boundary prisms (tetrahedrons) are not the most simple geometric bounding hull - spheres are cheaper (since we can think of a sphere as a point that has some 'thickness'),we can get away with projecting a single stabbing ray in the sphere's direction of a length equal to its travel per timestep plus one radius length - if we were to perform testing with a tetrahedron, we have to test (against each Plane of the box) four points , not two, and examine the relationship between 6 edges, not one. Since we actually ARE working with sphere geometries, nothing is cheaper.. but even if we were working with geometries which are not exactly spherical but close to it, we'd still use a spherical bounding hull during the macrocollision phase, and if the entity in question was long and slender and not at all spherical, we'd probably consider other sphere-like options such as cylinders, cones and ellipses before we'd go anywhere near tetrahedrons.
Tetrahedrons do have useful qualities, but I wouldn't suggest them as a useful collision hull unless we wish to enclose very complex bodies with a large number of tetras, useful for extremely accurate physical modelling but not something we'd often see in games due to the sheer number of calculations involved.

Posted on 2006-08-10 01:42:35 by Homer
There is a lot of lag when moving, in GameClient_1 to 13 all movement is smooth.
Why ? is this a yet to be solved problem, or is it meant to be this way?
Posted on 2006-08-10 21:36:20 by sleam
If your hardware is crap, try running in windowed mode, and maybe even making the window smaller.
The last few updates definitely have a problem I haven't tracked down yet, there's an unknown stack misalignment which may or may not contribute to the artifact you are experiencing.
Either way, the rate of motion is time-based, and should be the same no matter how crap your machine is, meaning that on low-end hardware it will appear jerky, especially at high resolutions... that is to say, the rate of change of position is related to Time, and not to the framerate... you are moving at N units per second, which is physically correct.

Posted on 2006-08-15 07:51:54 by Homer
Hi Homer,

From GameClient27 on I get the complaint:

``Heidi.bmpFailed Loading``

This file is mentioned within Player.x.
Did you forget to include the file?
If so, could you please include it at least once?

There is another file missing in GameClient34

``IntersectionTests.inc``

Could you also include this file?

Friendly regards,
mdevries.
Posted on 2006-08-21 15:58:09 by mdevries
Missing files attached.
Posted on 2006-08-21 22:34:03 by Homer
Hi Homer,

The rar file didn't contain the IntersectionTests.inc file.
It accidentally contain the file GameClient.exe though.

Friendly regards,
mdevries.
Posted on 2006-08-23 02:27:19 by mdevries

Here's that file.
Collision detection and response relies heavily on the ability to detect when entities are penetrating one another.
This file contains a number of primitive tests which are potentially useful in that regard, as well as some more general functions for working with planes and vector normals. Note that this file represents a mere fraction of the code I have available.
Posted on 2006-08-23 03:15:20 by Homer
Hi Homer,

After adding IntersectionTests.inc to GameClient_34 I get the following error message:

``IntersectionTests.inc(231) : error A2006: undefined symbol : r4_0``

I also have a request, if it isn't too much trouble.
Every time there is a new example attached I save a print version of this thread, overwriting the previous version.
But reading the printed version you can't see which example a specific part of the thread belongs to.
The reason for this is that the print version doesn't mention the names of the attached files.
Could you possibly add the names of the attached files to the text of those parts of the thread where they are attached?
Then you have an easy to read printed reference along with the examples.

Still a better solution would be that the names of attached files are added to the print version automatically.
Should that be addressed to Spook?

Friendly regards,
mdevries.
Posted on 2006-08-23 11:06:06 by mdevries
Yep, you probably should ask sp00k about that, but if you don't get the response you desire, I'll see what can be done in regards to a more print-friendly approach.

As for r4_0, just define it yourself as data.
I use the naming convention r4_XX to describe a 32bit floating point value ie a REAL4.
This I prefer to using just 'f prefixed' names such as fNull, because it indicates the bitsize of the data, so we can define r8_XXX and r4_XXX in the same application and not be confused.

``.datar4_0 REAL4 0.0f .code``

would do the trick.

It's probably a good example of my bad code, since there is an fpu opcode called fldz which loads zero onto the fpu stack, but in this case, we're performing a comparison, and we don't know what's already on the fpu stack, which only holds 8 values at any time, so it was a case of not wishing to upset the applecart so to speak.

As a side-note, I should mention that I modified my Normalize procedure last night, such that the fLen (scalar length of the input vector) is returned in eax, and also added another parameter so that there are separate output and input pointers (which can be the same if you like, or not). If the output param is NULL, the input vector is not normalized, but fLen is still measured and returned.
This means that procedure now performs a dual role, both calculating the magnitude of the input vector, and OPTIONALLY Normalizing it to unit length 1.0f
I felt that was a more nice solution than using a separate fMagnitude procedure and calling it from within Normalize, possibly it deserves to be renamed to something like NormalLength, which would imply that it can make a vector into a Normal of unit length, and/or measure the Length of a vector.
Posted on 2006-08-24 20:11:52 by Homer
Hi Homer,

Spook did the job!
You needn't add the names of the attached files.

Friendly regards,
mdevries.
Posted on 2006-08-26 08:18:37 by mdevries
possible for someone to compile this thread into a chm file, or a collection of complete file package containing all files, html, pics, stuffs for easy download, viewing n follow the flow? i'm not really following though, and i dunno if this thread has ended!
Posted on 2006-12-27 14:52:44 by kindman
This project is currently broken, and I've lost my enthusiasm for it..
I'm inclined to scrap this project and begin a new one, but it does contain a lot of useful information, and there seems to be very few resources similar to this.

Your request has been noted, and is not the first such request I've received.. perhaps we should poll this issue.

Nothing is ever truly lost - much of the code developed for this project has been incorporated into my other projects (especially my rigidbody physics engine, my bsptree generator, etc).
Posted on 2006-12-27 20:26:18 by Homer