Okay, math-heads, listen up!
Aug. 31st, 2002 02:22 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wolfwingsIf you've ever played a game called ShadowRun, specifically the third edition, there's an interesting set of rules regarding explosives. Specifically, they're relatively simple, X damage, -Y/m from explosion. But they DO count bounced damage off of one wall and rebounding as damage still.
So, I decided to try my hand at creating a system to visualize reflected damage radii per the ShadowRun rules. They have a nasty flaw, in that the damage ALWAYS bunches up, if you're more than X/Y meters in-game away from an explosion, there's no way it can hurt you.
But, this flaw can be exploited to calculate the damage of a set of blasts quite handilly. The trick, is to calculate things first as simple circles of 1-damage flat across the entire circle, and layer these circles to make the raising damage.
Then, reflect the circles against the walls, keeping track of accumulated distance as you go. There's a reason for this. Tracking from the explosion outwards causes aliasing errors from moire patterns from angle overlaps. Nasty.
So the trick here, is for any given 'blast circle' see which walls it 'touches' with a simple point-line distance calculation, then reflect them across the line. Then, go across the entire 'map' pixel by pixel, and check against each of the blast circles in turn. If one is 'over a line' then reflect back from there towards the original explosion point again instead, reflecting the lines back and forth as needed. In essence, ray-tracing to see which 'explosion radii' can be reached from each pixel, instead of the other way around.
Okay... now how many people did I just utterly confuse? >^.^< Should I post the source code I worked up, and see if anyone can see the anacronism that ended up in it, but that still seems to allow it to work right? :-)
So, I decided to try my hand at creating a system to visualize reflected damage radii per the ShadowRun rules. They have a nasty flaw, in that the damage ALWAYS bunches up, if you're more than X/Y meters in-game away from an explosion, there's no way it can hurt you.
But, this flaw can be exploited to calculate the damage of a set of blasts quite handilly. The trick, is to calculate things first as simple circles of 1-damage flat across the entire circle, and layer these circles to make the raising damage.
Then, reflect the circles against the walls, keeping track of accumulated distance as you go. There's a reason for this. Tracking from the explosion outwards causes aliasing errors from moire patterns from angle overlaps. Nasty.
So the trick here, is for any given 'blast circle' see which walls it 'touches' with a simple point-line distance calculation, then reflect them across the line. Then, go across the entire 'map' pixel by pixel, and check against each of the blast circles in turn. If one is 'over a line' then reflect back from there towards the original explosion point again instead, reflecting the lines back and forth as needed. In essence, ray-tracing to see which 'explosion radii' can be reached from each pixel, instead of the other way around.
Okay... now how many people did I just utterly confuse? >^.^< Should I post the source code I worked up, and see if anyone can see the anacronism that ended up in it, but that still seems to allow it to work right? :-)
*giggles* You're mostly right, but...
Date: 2002-09-01 03:09 am (UTC)But no, the 'moire' patterns would not accurately demonstrate the shockwave patterns, as they're radial moire, while the actual concussive wave of an explosion would be far, far smoother. The moire patterns also reduced the 'overlapping' areas of an explosion to an uncalculatable value, as the moire either instantly multi-layered the damage near the explosion, or caused very problematic rendering flaws further out.
Much like POV-Ray works, shooting the rays from the light isn't the best approach, starting from the pixels you're going to show and reversing the math to see if you can track back to the light often works better. :-) I just haven't added in refraction, transmission, or other aspects to the model yet, as the model isn't intended to support them currently.