3D Collission Mesh?
Moderator: Moderators
-
Sean Mirrsen
- Posts: 578
- Joined: 19 Aug 2004, 17:38
Why dont we just say that the centre of every poly is a hotspot, then we can ahve some nifty algorithm to merge areas with lots of small polys into a larger cumulative hotspot etc.....
That way attackers target whichever hotspot is nearest and whose angle is the closest to a tangent/normal (please someone cross off the one thats wrong) to the aproach angle fot he atatcker.
That way attackers target whichever hotspot is nearest and whose angle is the closest to a tangent/normal (please someone cross off the one thats wrong) to the aproach angle fot he atatcker.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
It uses both. Most good hit detection systems use two checks. Personally I'd like to see the move to the hitbox system. It's tryed tested and true and is more then adequate to meet the needs of an RTS engine. per poly or per pixel hit detection is the optimum for hit detection. But it's also slow as all fuck and way more then we need for an RTS engine. Per poly hit detection is only really nessicary when you are dealing with manual aiming if hittrace weapons at super fast movement speeds and insane targeting rangeszwzsg wrote:During the change between 61b2 and 62b1, the sphere collision was replaced by a footprint based collision.Warlord Zsinj wrote:I suggestion was raised whereby a cylinder could be used instead of a sphere, which would be less resource-heavy than a polygonal collision detection, but would still be able to approximate oblong objects far better.
SPRING DOES NOT USE SPHERE BASED COLLISION ANYMORE!
(save for flying units)
SPRING USES THE FOOTPRINTS DEFINED IN THE FBI OR TDF!
There are algorithms out there that allow for quick caluclations of collision boxes. I'd just need to dig deeper to find them.
I would think the calulation of collision boxes could be apart of the creation of the unit and saved in the new unit format as part of the entire scope of the unit. The engine could load the unit poly's and textures and also that units simple collsion box(s)
Some threshold limit would have to be in effect for the complexity of that saved collision box system. The greater the footprint, along with poly count the slightly more complex the collision box *could* be. not saying it should, but it could.
say a 1x1 20poly building or unit would have a max of 2 objects for a collision system, but a 4x4 400poly unit/building could have a max of 10 objects. And given your system specs if a unit is over this it could simplify things. We are, after all, looking forward to the next-gen RTS style, I think we need a system like this to achieve a fraction of what the big dev's can build.
-Buggi
I would think the calulation of collision boxes could be apart of the creation of the unit and saved in the new unit format as part of the entire scope of the unit. The engine could load the unit poly's and textures and also that units simple collsion box(s)
Some threshold limit would have to be in effect for the complexity of that saved collision box system. The greater the footprint, along with poly count the slightly more complex the collision box *could* be. not saying it should, but it could.
say a 1x1 20poly building or unit would have a max of 2 objects for a collision system, but a 4x4 400poly unit/building could have a max of 10 objects. And given your system specs if a unit is over this it could simplify things. We are, after all, looking forward to the next-gen RTS style, I think we need a system like this to achieve a fraction of what the big dev's can build.
-Buggi
I have a picture somewhere that explains why any suggestion of using shields is totally inadequate, and apart from shields I see no promise in keeping it. Box absed detection would be much better in nearly all cases and would be best when combined with the weapon collision mesh thing.
For shields I think the collision mesh thing would be best used, unless the modeller wishes a spherical bubble at whichc ase someone suggested a way fo implementing the spheres but constraining their radii so they where elongated ovals so that towers didnt have huge spheres around them btu rather bubbles.
For shields I think the collision mesh thing would be best used, unless the modeller wishes a spherical bubble at whichc ase someone suggested a way fo implementing the spheres but constraining their radii so they where elongated ovals so that towers didnt have huge spheres around them btu rather bubbles.
Hi there. As I've worked with collision meshes a fair amount, on a practical level, here would be my vote:
Have a sphere, with its radius determined as the farthest corner of the base * 1.3. This sphere is already more-or-less how collision works in Spring, plus a cube defined by the corners of the base. But multiplying that radius by a bit would make sure that even most weirdly-shaped things would be covered well.
This is what's generally referred to as a "quick-check radii sphere". Collisions between points or lines and such a sphere in a 3D space are fairly cheap to calculate. Basically, this would tell Spring if a given point or line (lines being important for true 3D collisions, as polygonal collisions are going to need to calculate lines between verts, instead of just watching verts in a point cloud) is even roughly "in the ballpark" of a given object. You could even have more than one of these- a much larger one, say, that was calculated first, and then a smaller one- and for each object in the gameworld that didn't register a final value of "true" for collision with the quick-check spheres, they'd get dropped from further checks (which, I suspect, is cheaper than the methods getting used now, but I haven't looked at the code for this).
When a point/line intersects the "quick-check" sphere, though, we should check for a hit on the model itself. Here, we should use cubes, built into the New Unit Format as part of the model. If the point/line intersects the cubes (a much more lengthy computation, to be sure, but relatively infrequent due to objects being removed from the check-queue pretty rapidly and not wasting CPU cycles) then we'd see a hit.
This would have several real advantages over the current methods:
1. More exactness of hits would add a great deal the visual accuracy of the game.
2. Modelers would have complete freedom to define the hitboxes, so they could have fine detail for very large things, and very crude details for small things. For example... a Peewee just needs a box. A Kroggie, on the other hand, needs boxes attached to limbs, etc. A HLT needs four boxes- one for the big box at the base, one for the thin top-mast area, and two for the guns. These objects would be attached to the model just like anything else, but would have to have a special naming convention- say, having a part_name with an ending like "something_hbox". They would, obviously, never be drawn, never be used for shadow calcs, etc.- they're just there to give the object real 3D hit-locations.
3. COB scripts could manipulate the hitboxes, and with minor tweaks to Spring, we could have damage that was different depending on what was hit, etc. Think about it- we could have a tank lose a turret... and that hitbox would no longer be there, either, making the tank's profile lower. Etc., etc., etc.
4. Units doing friendly-fire checks could send out a cone of "virtual rays" one tick before firing, to check and see if they have a valid path based on their rate of turn/swivel for the next tick. So they'd end up shooting friendlies less... or, worse yet, and all too common in this build of Spring... not shooting at all.
5. We could have bridges.
6. WE COULD HAVE BRIDGES.
7. Did I mention bridges?
8. We could have accurate, large-scale and complex colliding objects with interesting behaviors... like, say... buildings that actually disintigrated in somewhat-accurate ways, falling down, level by level as they blew up. And that's just one example.
9. We could have vehicles/Kbots leave tracks that were actual marks on the terrain, as opposed to just some very specialized decals.
10. We could have mods where hand-to-hand combat could be portrayed, in ways that looked pretty accurate.
I could come up with dozens of other cases where a fairly accurate (but not poly-to-poly perfect, or even close in most cases, and always based on boxes for simple, consistant calculation) would be better than what we have now. And using the multiple-sphere concept instead of whatever's being done now to remove objects from a given set of collision detections each tick might even be more efficient than whatever's being done now. In short... make collisions fairly accurate when they need to be... use something really, really un-accurate at all other times- and we can have something that works much better than what we have now, and doesn't drain much, if any, more speed :)
Have a sphere, with its radius determined as the farthest corner of the base * 1.3. This sphere is already more-or-less how collision works in Spring, plus a cube defined by the corners of the base. But multiplying that radius by a bit would make sure that even most weirdly-shaped things would be covered well.
This is what's generally referred to as a "quick-check radii sphere". Collisions between points or lines and such a sphere in a 3D space are fairly cheap to calculate. Basically, this would tell Spring if a given point or line (lines being important for true 3D collisions, as polygonal collisions are going to need to calculate lines between verts, instead of just watching verts in a point cloud) is even roughly "in the ballpark" of a given object. You could even have more than one of these- a much larger one, say, that was calculated first, and then a smaller one- and for each object in the gameworld that didn't register a final value of "true" for collision with the quick-check spheres, they'd get dropped from further checks (which, I suspect, is cheaper than the methods getting used now, but I haven't looked at the code for this).
When a point/line intersects the "quick-check" sphere, though, we should check for a hit on the model itself. Here, we should use cubes, built into the New Unit Format as part of the model. If the point/line intersects the cubes (a much more lengthy computation, to be sure, but relatively infrequent due to objects being removed from the check-queue pretty rapidly and not wasting CPU cycles) then we'd see a hit.
This would have several real advantages over the current methods:
1. More exactness of hits would add a great deal the visual accuracy of the game.
2. Modelers would have complete freedom to define the hitboxes, so they could have fine detail for very large things, and very crude details for small things. For example... a Peewee just needs a box. A Kroggie, on the other hand, needs boxes attached to limbs, etc. A HLT needs four boxes- one for the big box at the base, one for the thin top-mast area, and two for the guns. These objects would be attached to the model just like anything else, but would have to have a special naming convention- say, having a part_name with an ending like "something_hbox". They would, obviously, never be drawn, never be used for shadow calcs, etc.- they're just there to give the object real 3D hit-locations.
3. COB scripts could manipulate the hitboxes, and with minor tweaks to Spring, we could have damage that was different depending on what was hit, etc. Think about it- we could have a tank lose a turret... and that hitbox would no longer be there, either, making the tank's profile lower. Etc., etc., etc.
4. Units doing friendly-fire checks could send out a cone of "virtual rays" one tick before firing, to check and see if they have a valid path based on their rate of turn/swivel for the next tick. So they'd end up shooting friendlies less... or, worse yet, and all too common in this build of Spring... not shooting at all.
5. We could have bridges.
6. WE COULD HAVE BRIDGES.
7. Did I mention bridges?
8. We could have accurate, large-scale and complex colliding objects with interesting behaviors... like, say... buildings that actually disintigrated in somewhat-accurate ways, falling down, level by level as they blew up. And that's just one example.
9. We could have vehicles/Kbots leave tracks that were actual marks on the terrain, as opposed to just some very specialized decals.
10. We could have mods where hand-to-hand combat could be portrayed, in ways that looked pretty accurate.
I could come up with dozens of other cases where a fairly accurate (but not poly-to-poly perfect, or even close in most cases, and always based on boxes for simple, consistant calculation) would be better than what we have now. And using the multiple-sphere concept instead of whatever's being done now to remove objects from a given set of collision detections each tick might even be more efficient than whatever's being done now. In short... make collisions fairly accurate when they need to be... use something really, really un-accurate at all other times- and we can have something that works much better than what we have now, and doesn't drain much, if any, more speed :)
@Pxtl:
Sorry, I'm not trying to suggest that any of this is magical in nature :) As for collisions between objects... I'd have to suggest that they would be treated the same way as collisions between projectile meshes and object collision meshes. I am, again, utterly ignorant of how Spring handles collisions between the voxel-like meshes used for ground/water, but I'd suspect that we could very easily have a pathing routine that used the outer corners of the lowest collision mesh to determine pathing in general, and used to determine collisions between a bridge's collision mesh and an object, though. I'd bet that this would be no more expensive to calculate than the current method of determining collisions with the ground- after all, such a collision routine already drops all non-ground objects from its check, and then proceeds. In the current method, I'd have to guess that it doesn't even take other objects into consideration- this would merely add that step for each object.
One of the side-effects of this is that Rubble could be, as has been previously suggested, be made drive-over-able, among other things. In Spring game designs where the designers didn't like that, they could just make the collision mesh for the rubble (which, I would assume, would just be a cuboid in most cases- only extremely large ones would need multiples) high enough that units could not "step up" on top of it.
Sorry, I'm not trying to suggest that any of this is magical in nature :) As for collisions between objects... I'd have to suggest that they would be treated the same way as collisions between projectile meshes and object collision meshes. I am, again, utterly ignorant of how Spring handles collisions between the voxel-like meshes used for ground/water, but I'd suspect that we could very easily have a pathing routine that used the outer corners of the lowest collision mesh to determine pathing in general, and used to determine collisions between a bridge's collision mesh and an object, though. I'd bet that this would be no more expensive to calculate than the current method of determining collisions with the ground- after all, such a collision routine already drops all non-ground objects from its check, and then proceeds. In the current method, I'd have to guess that it doesn't even take other objects into consideration- this would merely add that step for each object.
One of the side-effects of this is that Rubble could be, as has been previously suggested, be made drive-over-able, among other things. In Spring game designs where the designers didn't like that, they could just make the collision mesh for the rubble (which, I would assume, would just be a cuboid in most cases- only extremely large ones would need multiples) high enough that units could not "step up" on top of it.
Impressive, but I find that the pathfinding considerations are large, and would need to be consulted with a redesign fo pathfinding compeltely, takign itno account the research presented on thsi forum and the resrearch done by those of us who have spent time such as myself gabba and those who have prior experience.
The question is not about the bridge having a sphere but what surfaces can units walk on and how to tie it into pathfinding and the physics engine correctly, they imply a 3D problem space for which we currently have a 2D solution.
The question is not about the bridge having a sphere but what surfaces can units walk on and how to tie it into pathfinding and the physics engine correctly, they imply a 3D problem space for which we currently have a 2D solution.