Multi Line Trace ballistics: changing velocity on overlap, aka changing trajectory on penetration

Edit: solved, details in next post.

I’m having trouble updating my linetraced bullets’ trajectory when they penetrate an object. I can change the bullet’s velocity but it does not effect the trajectory until the next tick. Effectively, if a bullet penetrates a wall it will still travel to the end of the initial linetrace, then change its trajectory based on the updated velocity.

Desired behavior is that the trajectory changes immediately when penetrating the wall, within a tick. There are many cases where the change is significant e.g. low speed, many penetrations in a single tick, etc.

If I call a new trace with new direction and speed/distance every time a bullet overlaps, how do I ensure the bullet travels the correct total distance/time for the tick? Physics substepping helps some cases, but does not address the problem and effects the entire project.

Context / current system:
I’m using multilinetraces for my bullets, all active bullets are structs containing their location and velocity (both vectors), and a few other things. All active bullet structs are in an array, each tick I loop through the array. I update velocity (gravity), add velocity to current location to get new location, and linetrace from current location to the new location. I process any overlaps, if a block occurs the projectile is marked for deletion.

I have bullet penetrable objects, which have a variable to determine how much it effects bullet speed. If a bullet linetrace overlaps a penetrable object, the bullet velocity is reduced based on the penetrable object’s variable. All works as expected if there are no overlaps.

**Red is the first tick, when the bullet is fired. **Bullet speed numbers are simply for illustrative purposes, since the velocity vector of the bullet struct does actually change correctly on each penetration.


need to update a trajectory using new linetraces multiple times in a single tick, each time it overlaps. There has to be some combination of vector math, recursion, or tracking linetrace time/distance that can accomplish this accurately! I think I’m missing something simple. Elegant or inelegant ideas appreciated so long as they use linetracing.

Writing the OP helped me think things through and I figured it out, the tick delta time and the time value returned by linetrace hits were the keys. I will write this post for future forums searchers and googlers. The key was of course multiplying time by velocity to get position changes, by changing the time proportions and carrying it over between bullet calculations I can maintain accurate simulation without messing around with the projectile velocity. My implementation is depth first when processing through the list of active bullets, fully calculating and updating each projectile completely before moving onto the next one. For my purposes this should not be a problem.

Using recursion you can iterate on a projectile until it has used up all its Tick deltaTime. Within my bullet trajectory calculation function, I get the Time output from the overlap hit, multiply that by tick delta time, and that gives the “time elapsed”. So, time remaining would be tick deltaTime minus that time elapsed. I update projectile location and velocity and pass that time remaining directly into a recursive bullet calculation call as the effective deltaTime. Working on server and clients can use an interface to ask the server to add a bullet to the active list. I dont know if that portion makes sense and this thing still has a lot of things to fix but its an improvement.

Implementation quirks and spaghetti code aside, if anyone knows another solution, perhaps a more performant or elegant or powerful one, I would like to hear about it. Thanks for reading!

within each tick, traces performed toward the “beginning” of the tick are green and traces “later” in the tick are red.