Calvin ✨

Yeah, it loops through each pixel in the LUT, and accumulates the falloff. It's an alternative to having a full-size render target and unique UV's for the object, which has limited resolution and removes x-amount of calls to DrawMaterialToRenderTarger (which is crazy slow)

Thanks a lot for the explanation. Yeah, it should be way performant compared to rtt probably on any situation where you draw same texture multiple times. Great idea!

I don't think you'll see a perf impact from looping in hlsl here because the branch isn't going to be non-divergent across the pixel group processed by the gpu. I think there's cheaper ways to do this though like splitting into a grid of possible impacts and picking the closest

is going to be non-divergent* oops! Basically it's going to be the same for every pixel (as long as you keep it that way) so each pixel can be executed in parallel Could be something unforseen though so I'd check in renderdoc

There's definitely room for improvement for sure, it's a very basic implementation at the moment. The major downside is I have to do 90% of the work inside the loop body, so as the effect gets more complex/interesting the cost starts to skyrocket.

Are you generating a distance (sqr) field to drive the effect? That's how I'd do it, but splitting it into cells (look at worley noise algorithms) could reduce a lot of the complexity at the cost of precise hits

Yeah so the loop essentially loops through the LUT texture and accumulates `distance(PixelPos, LUT.rgb) * LUT.a;` - eventually I plan to add a second column of pixels to provide the radius as well (think higher damage = larger effect)

I spent a hella-lot of time trying to work out if I could bake a data texture or pack info into the UV's to avoid the loop, but came up short on that idea everytime.. not sure there is a solution that doesn't involve at least some looping.