The Goal: To collect the color of the (closest?) pixel at the intersection point on a collidable mesh…to use in a Niagara system to color debris mesh. I’m in UE5 using blueprints.
This is what I’m using and it works BUT we are seeing a heavy drop in FPS when using. We are pretty sure it’s the capture pixel and read pixel that cause the drops.
Are there better / more efficient methods to collect this this collision color information?
reading pixel colour data is very expensive i belive - can you pre bake the data at all? ie landscape rvt or a top down capture of the scene colour?
alternatively you could get the UV on collision hit (there’s an engine option to enable this iirc) and then just look up the same texture as the material being used - although you might have to store a dictionary of the potential materials and what textures they’re using.
the last option might be projections - but it sounds like if it’s for moving debris pieces then that wouldnt work.
generally games just batch the debris types into surface types and spawn the appropriate ones that way - do you really need more control than that over the colours?
- do you really need more control than that over the colours?
Not sure yet. We have the surface type function in place already and works great; I think this might be a technical exploration to spice up some cinematics or certain gameplay elements. Ty for the approaches going to mess with them today. (baking could be an option too)
Is there a reason you arent using the physmats and the niagara gbuffer module?
Have a physmat for the colliding objects, spawn a niagara system with a gbuffer module and capture the color that way.
Is there a reason you arent using the physmats and the niagara gbuffer module?
We are using physmats. Didn’t know about the gbuffer module. Have you found it performant?
Update: Using Gbuffer in a custom Niagara module in GPU particles has proved the best solution for now. Can’t see a performance difference (yet).
Havent noticed a performance hit, but happy you got it working 
I assume the only drawback would be the limitation of the GBuffer being view depedent. So any offscreen (or occluded) collision will be invalid.
Awesome that Niagara allows us to do these things nowadays though
This is a valid drawback which matters more in multiplayer. I’m also noticing some issues with collisions being turned on with these particles as well. Will keep exploring and update.
I haven’t had the chance to test it in MP , but in that case I would author the fx to have a default look to avoid it just outputting black when out of view
I’m currently doing something similar for work, but I’m finding the middle ground is to have the GBuffer results more as the icing on top of the fx rather than relying on it entirely
