IMSabbel wrote:Well, i dont think cylindrical would be that great, because it really only fits to 2 or 3 towers.
If there is an improved collision model, than it would be wise to just go to bounding box(es).
Even a single box will be much better for most units (for eample, look at a big bertha and its _huge_ bounding sphere. A single box could be rotated with the turret and be half the volume of the sphere).
Also this would be much better for everything allready in box-format (like tanks :) ).
Those algorithms are very well researched and shouldnt be too slow...
Actually I think that both cylinders and bounding boxes give a comparable level of improvement over spheres. They both get rid of the silly bulges at the side, which no unit has, and they both allow for height to be altered independent of width, so that you can have tall thin units like freakers, MTs and LLTs and also short fat units like tanks, wrecks, metal storage, solars.
Agreed that a box would be better than a cylinder, which would be better than a sphere. It's just about adding more degrees of freedom to the collision detection. The point is that going to a bounding box is not a trivial code change, but going to a bounding cylinder is
and it should give a big improvement over a plain old sphere.
Contrary to the belief expressed by Weaver about "made on the fly" spheres, the whole point about doing spherical collision is that you don't have to make anything - the sphere just drops out of the maths for free. The wire frame sphere's you see in debug mode are drawn artificially - they're not actuall game elements.
The way you do spherical collision detection is simply by asking "how close is projectile P from the position of unit U"? Each unit has a fixed size R. If the projectile is closer than R then it has hit that unit, if it is further than R then it hasn't. That's it. No need to go calculating the sphere - it just happens that if you use this "how close is it" algorithm you end up with a sphere. Finding out the distance between any two positions is therefore a single line of code. Here's the psuedo-code:
Code: Select all
distance = sqrt((x1 - x2)^2 + (y1 -y2)^2 + (z1 - z2)^2)
To go to cylinders, instead of just specifying a radius (which is used in all three dimensions for spheres), you also specify a height. The cylinder is then defined by a circle (of radius R) in the horizontal plane and a height (H) in the vertical axis. So now your pseudo-code looks like this:
Code: Select all
2Ddistance = sqrt((x1 - x2)^2 + (y1 -y2)^2);
verticalDistance = abs(z1 - z2);
So the check for collision becomes thus, ever so slightly less simple, but still a one line check:
Code: Select all
collision_detected = (sqrt((x1 - x2)^2 + (y1 - y2)^2) < unit_width)
AND (abs(z1 - z2) < unit_height);
Both of these are extremely simple. The main issue in changing to the above (I'm guessing) will be in calculating the bounding cylinder in the first place - I've no idea how the game gets the radius for the sphere.
The main point about both spheres and cylinders is that they are approximations which work independent of the unit's orientation. All you have to know is the unit's position, and its size (expressed as either one or two parameters). The problem with anything more complex is that you need to keep track of which way the unit is facing and even which way it's weapons are pointing, in order to get the bounding box right. Not only that but you're no longer talking about a line or two to calculate if the shot is within the bounding box.
I hope this explains why cylinders are a great idea given the level of improvement we would get for relatively little effort.
Cheers
Munch