Accurate blast damage that wraps around walls and how many raycasts are too many?

Help and Feedback Scripting Support
, ,
1

I have designed a blast damage system that works by the following algorithm:

  1. 64 points are generated and evenly spread across the surface of the blast’s sphere, raycasts from each and every single point back to the center of the explosion are made, if the point can’t see the blast’s original position or if it’s occupied by something (GetPartsInBox with size of Vector3.one * 0.05) then this point is discarded and doesn’t participate in raycasting towards potential characters.

  2. From every single one of these points, a raycast is made towards characters that are within the blast radius

  3. If even one of these attachments can see a character, the character is counted as exposed and is added to the table of characters that the explosion will damage. The raycasting for these “hit” characters fully ceases, meaning no other points will raycast towards them in an attempt to detect.

My question/issue is: how optimal is this for production games? Would this be bad if, for example, 10 players all stood within the blast radius of one grenade? Can anyone tell me if anything sounds off to you about this? I’m mostly worried about the large ray counts that might slow down the server. If you think what I’m doing is bad or might be, please suggest a better algorithm.

Whatever you suggest, it needs to be able to go around corners/obstacles so players can’t hide from a grenade if it goes off just around the corner

2 Likes
2

I never really worked with raycasts that much so my reply might be useless
but I dont think that 10 raycasts would hurt the server performance that much

1 Like
3

I am not fully sure if that works for you but if you use a standard or customized Roblox explosion what I would recommend you can just use the :hit() event to check if the explosion hit something and how far it is away if it has a humanoid, you can damage him and also scale the damage output with the distance from the explosion. You can check out the documentation to learn more.
Hope that helps

1 Like
4

Abysmal answers from the both of you that both perfectly wrap around the point of my post. Well done. Did you use an AI summary to get those big smart words out of the way?

1 Like
5

Your intention to handle explosion occlusion and corner wrapping is great, but running 64 GetPartsInBox spatial queries plus up to 640 raycasts per explosion will definitely cause server physics spikes, especially during intense firefights with multiple grenades.

The main performance issue with your current approach is that it is world-centric—it spends heavily calculating points in empty space where no players might even exist.

Here is the industry-standard, target-centric approach that achieves the exact same corner-wrapping effect with a fraction of the cost:

1. Reverse the Logic (Target-Centric Query)

Instead of sampling 64 points in space first:

  • Use workspace:GetPartBoundsInRadius once at the explosion epicenter to collect only the HumanoidRootParts of targets within range. If 0 players are inside, performance cost is virtually zero.

2. Multi-Point Character Raycasting (Body Sample Points)

For each detected target, cast rays from the explosion center to 5 key points on their character:

  • Head, HumanoidRootPart, Left Shoulder, Right Shoulder, and Feet.
  • If any of these rays hit directly without hitting terrain/walls, the player takes full/calculated damage.

3. Corner Wrapping / Diffraction (Lightweight Origin Sampling)

If you want explosions to curve around tight corners/cover:

  • Instead of 64 origin points, generate just 4 to 8 origin offsets around the grenade (e.g., +1/-1 stud on X, Y, Z axes).
  • Only run these secondary origin rays if the direct line-of-sight check fails! This means you only spend extra performance on players who are actively hiding behind cover.

Summary Comparison:

  • Your current algorithm: Always executes 64 spatial queries + up to $64 \times N$ raycasts (where $N$ is target count).
  • Optimized algorithm: Executes 1 spatial query + $5 \times N$ raycasts (and only 4–8 extra rays for targets in partial cover).

This will keep your server execution time well under 1 millisecond per explosion while maintaining highly accurate cover/diffraction mechanics!

6

This is really good advice and I have gone ahead and implemented some of this before your input. However please refrain from the use of AI in the future (it seems to me that you used AI)

1 Like