General > Announcements
Version 2.42.5 Released
EricL:
--- Quote from: Elite ---Woohoo!!!
After giving my sims some friction, and modifying my bots so that their antibirthtie genes worked, my shot bots not work very, very well - incredibly close to how they were supposed to work in 2.37.6
(in fact, the only difference I can see to Una's at all is the dynamic sizes)
Very nice :D
Well done Eric!
:clap:
--- End quote ---
Thanks Elite. That's good to know and it's nice to hear that people find the work I'm doing useful.
For large sims with lots of shots, perf did take a step backwards in this version. The execution order of the shot collision routine is O(S * B) where S is the number of shots and B the number of bots. The added range of return shots increased the average number of shots in any given sim by perhaps 25% and the routine itself is quite a bit more CPU intensive, so this becomes quite noticable when either B or S or both are large.
I have some ideas to improve it. Poof shots for example. Right now, 20 shots are created every time a bot dies and even if the bot is at 0 energy at death, each of those shots is a -2 shot with a healthy range and 240 energy!!!! Death adds energy to the sim if any bot is close enough to absorb the shots. This is magic energy created out of whole cloth independent of anything else. The shots go off in random directions, but being next to a bot when it dies is a great way to get energy. It's things like this that make managing the sim energy flow super frustrating.
I'd like to change it so that energy/body is conserved, that the energy in the poff shots sums to that left in the bot in it's energy/body when it died. I'd like to create fewer shots if the energy isn't there to support them. This would reduce the average number of shots in a sim and speed things up.
I think there are opportunities for doing a better job of ruling out possible collisons up front as well.
But the real payoff would be if someone has a computationally fast way to find the minumum distance between two points moving indenpendently at different velocities in a plane over a time period 0 < t < 1 without looping through and testing different points in time. That is the meat of the collision routine and finding a faster solution would speed things up tremendously.
Edit: Had a math error. Death shot energy is actually 240/shot not 9600.
Numsgil:
--- Quote ---I have some ideas to improve it. Poof shots for example. Right now, 20 shots are created every time a bot dies and even if the bot is at 0 energy at death, each of those shots is a -2 shot with a healthy range and 240 energy!!!! Death adds energy to the sim if any bot is close enough to absorb the shots. This is magic energy created out of whole cloth independent of anything else. The shots go off in random directions, but being next to a bot when it dies is a great way to get energy. It's things like this that make managing the sim energy flow super frustrating.
--- End quote ---
I thought poffs were strictly ornamental.
--- Quote ---But the real payoff would be if someone has a computationally fast way to find the minumum distance between two points moving indenpendently at different velocities in a plane over a time period 0 < t < 1 without looping through and testing different points in time. That is the meat of the collision routine and finding a faster solution would speed things up tremendously.
--- End quote ---
I have a huge book on collision detection code. Sounds like you want closest point between two line segments defined parametrically.
However, I think you can expand this more easily to a test between a swept sphere (capsules) and a line segment that returns the initial point of contact instead of the point where the contact is the closest.
Allow me a day or so to read over my book (it won't take me a day to read it, it just might take me a day to get around to it ) and I'll come back with something.
Numsgil:
Oh, and as to shot to bot collision complexity, I'm (slowly) implementing a hgrid for bots in the C++ version. Collision complexity would then become roughly O(s), ie: linear instead of quadratic.
Numsgil:
Here's what I have so far:
a = botopos vector
b = shotopos vector
c = botvel vector
d = shotvel vector
collision occurs if:
--- Code: --- t^2 (c - d) dot (c - d) + 2t (a - B) dot (c - d) + (a - B) dot (a - B) - (bot radius) ^ 2 <= 0
--- End code ---
That's a quadratic equation of t, so you just have to solve via quadratic formula to find two t's. The one that's the closest positive value to zero is the time of impact.
Then you just plug t back into the equations of motion of the shot and bot:
ie:
--- Code: --- botpos(t) = a + t©
shotpos(t) = b + t(d)
--- End code ---
I'll post the final solution later tonight in pseudocode if someone doesn't beat me to it.
Numsgil:
Hehe, okay, this is taking less time than I thought
--- Code: --- deltapos = botpos - shotpos
deltavel = botvel - shotvel
L2vel = squaredlength(deltavel)
t0 = -(deltapos) dot deltavel + bot radius * sqrt(L2vel)
-----------------------------------------------
L2vel
t1 = -(deltapos) dot deltavel - bot radius * sqrt(L2vel)
------------------------------------------------
L2vel
bool uset0 = true, uset1 = true
time t <-- collision time
if(t0 < 0 || t0 > 1)
uset0 = false
if(t1 < 0 || t1 > 1)
uset1 = false
if(uset0 = false and uset1 = false)
the shot and bot don't collide
if(uset0 = true and uset1 = true)
t = min(t0, t1)
else if(uset0 = true)
t = t0
else
t = t1
Now that we have t, we can find the pos of the bot and shot when they collided:
posbot = oldbotpos + t * botvel
posshot = oldshotpos + t * shotvel
--- End code ---
That's all from the top of my head, so someone feel free to double check the figures. The basic algorithm is sound though (construct a quadratic and solve it)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version