View Full Version : Collision Detection

02-18-2011, 04:09 AM
I know there has been a lot of people saying "We want collision detection! Blah! Blah!" I'm not going to be that type of person that just demands a feature. Instead, I was wondering, if the people creating Alice 3.0 could access all of the "points" of any particular object.

For example, if we assign a letter for every three-dimensional position, if object1 contains points in the positions {a, b, c, d} and object2 contains points in the positions {d, e, f, g} then it would show as a collision since they share a common point {d} in the same position. I know that most objects contain more than four points, so I'm not sure if checking for collisions using this method would be practical.

So yeah, Alice could have a built in "isColliding" function, using two parameters for the two different objects and the result would return true if the any points in the first object are in the same position as the second object.

So yeah... to sum it up in hard code:

isColliding = function(object1, object2)
//object.points is an array containing all the points in that object.
//intersection is a function that returns the commonalities between two arrays
newArray = intersection(object1.points, object2.points);
if (newArray.size >= 1)
return true;

I don't know what data the Alice development team has access to, but hopefully this might help. :)

02-20-2011, 01:42 PM

02-20-2011, 04:28 PM
There is a slim chance that to objects would share two points exactly. Shapes are composed of points that are positioned at arbitrary positions, and polygons are drawn between them. So there wouldn't be collisions except in very rare circumstances, and never in the places where collisions would be useful.

02-21-2011, 11:37 AM
Collision detection is one of the many unfinished features that the Alice 2 developers were going to include. In my search for hidden features in Alice I uncovered the hidden collision code within the java source that they never fully implemented.

Its also interesting to note the built in collision available when you add the event "let arrow keys move camera". If you move the camera into an object it will have built in collision detection.

02-21-2011, 06:11 PM
I guess I didn't have a good understanding of how 3d objects are rendered in Alice. I assumed that objects are just a continuity of points, as opposed to discrete points connected with lines to form triangles. I totally forgot about the whole camera thing, so I am glad to know that the Alice development team has something going with the collision detection. However people, we must remember that the camera is just an arbitrary point in space. Going from point-to-object collision detection to object-to-object collision detection may or not be the thing that's holding the collision detection engine back.

02-27-2011, 04:09 PM
Couldnt they do polygonal collision in alice but built in?

David B
02-27-2011, 04:51 PM
I have a question. What does this post mean?:


02-27-2011, 07:01 PM
I have a question. What does this post mean?:

Its what people post when they want their thread to be viewed again. Bumping a thread just brings it back up to the top of the "New Posts" section so that it is more likely that people will read it.

05-12-2011, 02:47 PM
doesn't always work though :D

11-14-2011, 04:51 PM
That is brilliant, but I'm afraid that will require a point for each single polygon.
Otherwise, it would be the exact same thing to use as "[Object] Distance to [Object]".

Mr Kidnapper
11-14-2011, 06:37 PM
Well object distance is based purely on pivot point and only involves points in a 1:1 scale.
But lets insert numbers into the equation. An average model has four vertices per polygon. All, if not most, of these vertices are reused (And can be reused practically infinitesimally) so let's say each polygon (Quad) creates one vertex and reuses three other vertices. Let's also say I'm jumping the usual average margin, and our world contains 100,000 polys. That's still somewhere near 100,000 vertices. Let's say our collision check is simple; it searches for the distance of polys, derived by finding the geometric center of each vertex associated with the poly (X,Y,Z) and compares them with the direction they are considered facing, also described by XYZ. If the distance between them is negative, then they collide.
This could take, what? Four calculations per poly? Now lets assume this calculation is done twenty-four times per second, because "smooth" human framerate is considered 24 frames per second. 9,600,000 calculations. From a quick google, you may read that the uber slow Pentium D Processor does 2.3 billion calculations per second. Constantly calculating collisions for 100,000 polys doesn't sound like much. Technically it is, but let's ignore that.

At any rate, I have an idea for improvement. There is no game engine in the world that seriously checks collision for every poly in an object, since scenes tend to reach millions of polys fairly easily. They use simple shapes between six (boxes) and ~500 polys (Helicopter) for any given object. They call these simple shapes a "Proxy" object, and they are named that, and they do the calculations on these proxy objects.

So the idea is: Add a true/false box in the Seldom Used Properties list that reads "Is Proxy." 3D Modelers will make a subobject hierarchy that includes the proxy objects, and when the box reads "True", collisions will be calculated for that object.
Why use a property box? Because going into the Alice Object Gallery that seldom exceed several hundred polys and adding twenty more for a proxy is pointless. Only someone who is seriously inclined to add collision will go through the extra steps to add a proxy to reduce lag.

Edit: The serious problem with collision lies in what you're going to do with it. In game engines, a lot of power is consumed calculating physics from collision. So, you're going to have a simple IsColliding function? There's nothing wrong with this if you want to make an object absolutely stop upon impact. The problem is, physics needs more information. Magnitude and speed and whatnot. You can get this from the object itself but the object needs to be about as complex as a sphere.

11-14-2011, 07:53 PM
I think simple box collision is the best way to do it in Alice... no need to get complicated and use Battlefield 3 type collision detection where you can walk on every polygon. I mean, even the Call of Duty games still use box collision for most objects (except slopes).

Mr Kidnapper
11-14-2011, 08:02 PM
Call of Duty was never known for its graphics.

11-14-2011, 08:15 PM
Call of Duty was never known for its graphics.


Collision detection has absolutely nothing to do with graphics

Mr Kidnapper
11-15-2011, 09:58 AM
Oh sure it does. Collision detection is based on polys. While the polys remain unseen, it doesn't mean it doesn't have great impact on graphics or gameplay.

11-15-2011, 01:38 PM
Unseen polys are not graphics. Graphics are the art of the game; the actual functionality lies in the code. I know what your saying though, I just wanted to make clear that CoD's graphics don't have to do with its collisions. In another game like BF3 though, the graphics might have to do more with collisions, but even there its really two very different things.

06-24-2012, 09:04 AM
I completely agree that collision detection should be built into Alice. However, with many objects, things could get unnecessarily laggy. I think that Alice objects should have an isCollisionOn property. This way not every single on of the twenty trees in your game don't have to check for collision every time.