Niagara Mesh Particle returns Particle Position 0.0.0 on material when passed through a vertex interpolator and a texture is sampled with ParticleSubUV Properties

Development Rendering
, ,
1

Hi Epic,

Seems I have encountered an issue with Particle Position when using Mesh particles with ParticleSubUV Properties. When passing the Particle Position through a vertex interpolator, and using a Particle SubUV Properties to sample a flipbook, the results received on the mesh particles are a position of 0.0.0. This doesn’t occur with sprites or regular Texture Coordinates.

Could it be possible to look at it?

Thanks!

[Attachment Removed]

2

Steps to Reproduce

  1. create a material where particle position is passed through a vertex interpolator and debug values provided
  2. set a texture sample to write into the base color or any other input
  3. Create a Particle system with a regular sprite and a mesh particle
  4. observe that when using a regular Texture Coordinates the position returned will be correct for both
  5. As soon you sue Particle SubUV Properties coordinates, the results are wrong only on the Mesh Particle, returning 0

[Attachment Removed]

3

Adding pictures here as I am not sure if it has been uploaded in the bug

[Image Removed]

[Attachment Removed]

4

Hey there! Thanks for the clear repro. I was able to reproduce the issue in 5.8.1 as well and I’ve filed an issue for the team to look into further. (UE-389234, should populate in a few days). In the meantime, can I ask why you need to pass particle position through the vertex interpolator? For what it’s worth, I think the issue is more broadly that any value passed through a VertexInterpolator when SubUVs are used will be garbled like you saw in your test.

[Attachment Removed]

5

That definitely makes sense! Good news, the fix is already checked in to UE6/Main at CL56388577 (GitHub)

I think I would have approached that as something I could do once per particle on the Niagara module and pass that in via a Dynamic Material Parameter. The Visibility module on a mesh renderer has min and max camera distances, but those aren’t passed into the material the same way that PerInstanceFadeAmount would be for an instanced static mesh. I suppose you could also potentially re-bind Particle Random to your per-particle fade amount if you’re not using that value.

Thoughts?

[Attachment Removed]

6

hey Matt Thanks! I’ll ask our engineers if we can get that fixed on our branch.

I think it’s a good idea what you mention, as then the cost will be even less if they are particles, as will only calculate it once. Unfortunately though usually develop two types of fades, one that is per particle (that would work great with your method) and another that is world space based on per vertex/pixel proximity, which wouldn’t work well with your mentioned approach, that’s why I end up building the features in the shader itself.

I’ll definitely keep in mind though your approach as I find it also interesting :smiley:

Thanks for the suggestions and the fix!

[Attachment Removed]

7

Hi Matt! Thanks :smiley:

The reason why I pass particle position through a Vertex Interpolator is due some optimizations that I was adding to a Fade By Distance function, so I can do all the fade by distance calculations by vertex rather than in a pixel basis and reduce some of the cost in the fragment pass.

As I am using in that case particle position and camera position for those then I end up having that issue only in Mesh Particles, making the fade by distance not viable in that case on the vertex shader and reducing the optimizations possibilities.

[Attachment Removed]