Collision detection?

[Buggi]

Okay, the sphere system works for at least 80% of all items in Spring. Planes, kbots, projectiles, even tanks work well with this system.

However, there are a couple areas that could use the benefit of a box based system. Factories, walls, and other wide/long objects. Large ships for example.

Warning, the following URL contains big words and math

http://www.mlahanas.de/CompGeom/opt_bbox.htm

For a wall that's 2x8 and height 30 or even a regular tower that's 2x2 only 10 high... a rectangle (or parallelogram) seems to be the more appropriate choice.

I'd like to hear what SY has planned for collision detection. If anything.

-Buggi

[[K.B.] Napalm Cobra]

What we really need is polygon based collision detection.

Now before you boo me off the stage for suggesting such a demanding procedure for an rts of this scale let me point out a few things...

1) TA models were quite low polygon compared to alot of games.

2) You can still use sphere based collision detection to cut down on testing everything, ie, it would only be tested if there is a collision detected with the spheres.

3) It makes it alot more realistic.

[Buggi]

While I agree it would be crazy-mad to program.

Say you average out the number of faces per unit to say... 150, times 500+ units, that's a LOT of calculations per second.

I agree, it would be very realistic, and in a perfect world that's the way it would be done. But with the model's we have and the direction of the project I suggested something with much closer goals than a per-poly collision system.

-Buggi

[Warlord Zsinj]

Plus I think many people want to take advantage of the fact that Spring can easily have higher polygon rates, and make some more detailed units.

[[K.B.] Napalm Cobra]

Bounding sphere or box are fine for unit to unit collisions, I was talking about weapon to unit collisions.

[Cheery]

I know one quick method for calculating convex meshes. It handles things as interfaces. Myself have found it as really good solution. The idea is to make interval tests from surface normals. It's quite simple and works. If you need to detect contact points, you need another algothrim for it because this doesn't calculate them. It's also easy to do basic piercing detection for this algothrim, that way it cannot go trough objects with high velocities and low integration values.

2) You can still use sphere based collision detection to cut down on testing everything, ie, it would only be tested if there is a collision detected with the spheres.

Oh no no. You cut out the important part called oct-tree, maybe quad-tree is good too for this kind of game. This way you can divide out very many calculations at once. The quad tree cuts any collision detection calculating into minimum. I gues you have this already because you can render the game at all on my comp and you have some values in your settings.exe nobody knows how to use.

And one thing yet, Warlord Zsinj...

CONVEX COLLISION MESH IS NOT SAME AS RENDERED MESH!!!
If you use rendered mesh as convex collision mesh, you encounter problems really soon, it's very possible your rendered mesh is not convex.
Another problem is that, your collision meshes are something like 12-40 triangles, drawn meshes are ab. 500 or even 4000 triangles. So they are really little much different to being mind as same thing.

[SJ]

I agree that the current system isnt perfect and could use some improvements. So if someone will write a better system that doesnt give a big cpu hit we will include it. A polygon based system might actually be usefull. Maybe not for ingame collisions but for the user input which is where the current systems deficits is felt the most, at least by me.

Note that unit-unit and unit-feature collisions is already mostly based on the footprints (square/rectangles) rather than spheres.

[Cheery]

One guy had some good sources for that, wait until I found that guy.

His name were Olivier Renault.
http://uk.geocities.com/olivier_rebellion/

http://uk.geocities.com/olivier_rebellion/Cube3D.zip Check out if you would have some help from this.

[Sean Mirrsen]

Actually, let the modder define a "collisionmesh" piece in the unit model, that will be very low-poly (50 faces at most, probably), but vaguely representing the outline of the unit. That way, there will both be acceptable collision accuracy, and acceptably low cpu costs. Of course, that makes the old mods incompatible, but they could use the current system instead.

Oh, and btw, TA used per-polygon collisions for weapon hit checks.

[[K.B.] Napalm Cobra]

Smashing good idea, you could probably just use current models for the mesh and build new models around them.

[GrOuNd_ZeRo]

Perhaps the polygon detection would be best.

Ragdoll phychics would be awesome for Kbots BTW, doesn't that use polygon detection? or does it just use bounding boxes? anyway, it's probably better if all parts of the model (defined in the script) have bounding boxes instead of spheres.

I dunno...

[Buggi]

I was talking collision detection on a more projectile and UI dimension.

Perhaps it could be simplified for buildings... take the max height of that building and instead of a sphere, a box from the groundplate up to the max height. That way a 2x8 wall of height 10 will have a 2x8x10 box for it's collision detection instead of a massive sphere.

Same for Tower-like structures.

-Buggi

[Min3mat]

this would help SO much for defenses...u put guardians on the hill so they can fire over the rest of your defense (normally HLTs/units in my case )... and coz of silly collision system don't fire!!! the low-poly idea sounds fine