Ok, somebody with better higher-math skills, please let me know... when calculating hits and checking hitspheres... is it faster to evaluate hitspheres that are powers-of-two, or is it better to use powers-of-two minus/plus one?
Just a minor thing, but I've been wondering for awhile, since I discovered in NanoBlobs development that if you lower the hitsphere sizes past 8 (1 Spring "square") then it requires greater and greater compensation on the weapon's collisionsphere to properly detect hits. I've been using powers-of-eight ever since then, but I'm wondering if I really need to use powers-of-eight minus one, for the fastest possible evaluation. Any further light on this topic would be welcome.
Stupid Question: hitsphere evaluation efficiency
Moderator: Moderators
argh, I should be inclined to say something that runs the equation X^n where in is our number rather then (X^N)+1 due to the fact that it is using a pow operation and an adder operation.
my wonder is whether or not they are using pow or X*X because Pow is less efficient when we are just using something times it's self(we did some tests in a game one day at uni).
although.. in runtime calculations the +1 is struck off anyway :)
my wonder is whether or not they are using pow or X*X because Pow is less efficient when we are just using something times it's self(we did some tests in a game one day at uni).
although.. in runtime calculations the +1 is struck off anyway :)
AFAIK, there are no such artificial limits in Spring on hitsphere sizes. At best these effects are side effects of the hitsphere size (like more/less units fitting in a quad [sector of the map with its own unit & feature lists]).
Spring doesn't use pow to square a number (at least I never noticed it in the code), that would be a waste. As far as I have seen, it also doesn't check distance (requiring a square root) but checks squared distance whenever possible.
Purely technical I don't really see any way to optimise hitsphere code so it runs significantly faster when the spheres are 2^N or other "round" numbers.
EDIT: and about your last point, I'd guess that could be because hits are only tested using hitsphere when the midpoint of the weapon is over the footprint of the unit (not really sure this is true though, I always keep forgetting which collision code does this).
Spring doesn't use pow to square a number (at least I never noticed it in the code), that would be a waste. As far as I have seen, it also doesn't check distance (requiring a square root) but checks squared distance whenever possible.
Purely technical I don't really see any way to optimise hitsphere code so it runs significantly faster when the spheres are 2^N or other "round" numbers.
EDIT: and about your last point, I'd guess that could be because hits are only tested using hitsphere when the midpoint of the weapon is over the footprint of the unit (not really sure this is true though, I always keep forgetting which collision code does this).
Spheres are the cheapest thing to calculate collisions with.
Anything else requires significant more calculations. Though one could choose to implement a system where first the sphere is checked and only if that "hits" the more expensive shape is checked.
(The most costly issue with other shapes is that all not point symmetrical shapes either need to be rotated before the collision can be detected or need to be implemented in a rotation independent way, both of which usually take quite some math
.)
Smoth, sure, if someone makes a patch...
Anything else requires significant more calculations. Though one could choose to implement a system where first the sphere is checked and only if that "hits" the more expensive shape is checked.
(The most costly issue with other shapes is that all not point symmetrical shapes either need to be rotated before the collision can be detected or need to be implemented in a rotation independent way, both of which usually take quite some math
.)Smoth, sure, if someone makes a patch...
TBH you then lose the entire point of using a different shape in the first place: after all a box just looks like a sphere if it spins fast enough.
The only thing needed in that case is being able to set the sphere size, which is already possible IIRC.
EDIT: though e.g. a cylinder would be the most logical in that case, as usually stuff sits reasonably upright in Spring (and a cyl is still point symmetric in 2 dimensions after all)
The only thing needed in that case is being able to set the sphere size, which is already possible IIRC.
EDIT: though e.g. a cylinder would be the most logical in that case, as usually stuff sits reasonably upright in Spring (and a cyl is still point symmetric in 2 dimensions after all)
Boxes would be necessary for things like walls though. We already know better than using non-square footprints on mobile units but buildings and features should be able to use them for their collision. Buildings only happen in 90° rotations anyway.
Non-rotating (i.e. permanently upright, units aren't on steep slopes very often so noone would notice) cylinders are fine for everything movable. They're just an approximation anyway. Would make it possible to have e.g. tanks with a lower profile while mechs could be "thinner" but higher. Of course there are long (z axis), thin units but support for those can wait until later, cylinders would be a great first step.
Non-rotating (i.e. permanently upright, units aren't on steep slopes very often so noone would notice) cylinders are fine for everything movable. They're just an approximation anyway. Would make it possible to have e.g. tanks with a lower profile while mechs could be "thinner" but higher. Of course there are long (z axis), thin units but support for those can wait until later, cylinders would be a great first step.
I still say that we should just link multiple spheres to a Unit and specify where they are through a FBI notation, default being the one that is currently specified. That would cure almost all of this- the other hitspheres would change orientation/position with the origin of the model, just like the main one, and it could be as cheap as it is now, for things that can be decently represented with one sphere, up to fairly expensive, for things like long battleships, which might have 10 spheres in various spots. 10 hitspheres per unit is not something any sane modder would do on a regular basis, but it'd make large, skinny, or irregular things a lot more practical.
The only real problem with this is the code that all expects one sphere to determine collisions- things like inter-unit collisions, etc.
Oh, so the answer to my question was, "so far as we know, powers of X will not change the efficiency of the hit-detection math"? Okie doke, that keeps things easy...
The only real problem with this is the code that all expects one sphere to determine collisions- things like inter-unit collisions, etc.
Oh, so the answer to my question was, "so far as we know, powers of X will not change the efficiency of the hit-detection math"? Okie doke, that keeps things easy...
For collisions:
Spring doesn't use spheres.
Spring use sphere intersected with boxes.
Because the shot must not only be within radius it must also be within footprint!!!!!
So, if hitsphere radius << footprint, then the collision volume is a sphere. And if hitsphere radius >> footprint, then the collision volume is a tall rectangular tower.
Okay you can now resume talking about how Spring would be so much better if someone wrote a patch to add features that are already frigging there*, like usual.
(I admit current system isn't perfect since you can't have vertically short & horizontally fat collision volumes. And you can't have hit volume elongated along one horizontal axis and not the other either.)
* assuming corresponding Spring code hasn't been rewritten since I last tested
Spring doesn't use spheres.
Spring use sphere intersected with boxes.
Because the shot must not only be within radius it must also be within footprint!!!!!
So, if hitsphere radius << footprint, then the collision volume is a sphere. And if hitsphere radius >> footprint, then the collision volume is a tall rectangular tower.
Okay you can now resume talking about how Spring would be so much better if someone wrote a patch to add features that are already frigging there*, like usual.
(I admit current system isn't perfect since you can't have vertically short & horizontally fat collision volumes. And you can't have hit volume elongated along one horizontal axis and not the other either.)
* assuming corresponding Spring code hasn't been rewritten since I last tested
I still think the best approach is just to allow for a single unit to have multiple spheres - one sphere for each part, using an overall sphere that covers all the parts to optimize out checking each individual part-sphere if the entire unit is missed. A collision model that accurately represents whitebase could be done using a dozen spheres. Smaller units don't need that detail, so just use a single sphere for them.
edit: the real probelm is with blast radii - which sub-sphere would you use? The closest? All of them (so a five-sphere unit becomes more vulnerable to explosions)?
I'm curious about blast radii - when determining if a unit is harmed by an explosion, is it distance from center of explosion to center of unit-sphere, or to surface of unit-sphere?
edit: the real probelm is with blast radii - which sub-sphere would you use? The closest? All of them (so a five-sphere unit becomes more vulnerable to explosions)?
I'm curious about blast radii - when determining if a unit is harmed by an explosion, is it distance from center of explosion to center of unit-sphere, or to surface of unit-sphere?
For your last question, see Explosion() in CGameHelper (damage is done directly if the distance from the boundary* of a unit's hitsphere to the center an of explosion is less than 4 times the explosion speed, else it's queued).
* except for submarines and above-surface explosions (to which the center-to-center distance applies)
* except for submarines and above-surface explosions (to which the center-to-center distance applies)
To clarify, when two units are under control, the foot print is what determines when two units "bump". However, if one of the units is skidding, then the collision spheres come into play. The fact that collision spheres could extend beyond the footprint is what I believe cause the old "Tightly packed group of cans destroyed by a single leveler"zwzsg wrote:I overheard that was changed very recently. Confirm/deny?Also the "bumping" uses the collision sphere, if the spheres touch the units try to move away no matter where the footprint ends.
Recent changes, however, make is so skidding units only collide when they are also moving toward each other, and don't teleport them outside each other's collision sphere.