When using a Curve For Colors data interface from a Niagara Parameter Collection, GPU emitters that reference it appear to not correctly connect the actual source NPC curve to the curve that is being compiled into the emitter’s GPU update, resulting in it using a default-constructed (entirely empty) curve when it goes to actually execute the update on the GPU. Other curve types (Curve For Floats, at least) work correctly.
I’ve been digging into this for a few days and have been unable to track down where things break here. Nothing about the behavior of the UNiagaraDataInterfaceColorCurve seems to be any different than any of the other curve types that do seem to work fine, and I’m somewhat convinced that the issue is somewhere deep inside the graph compilation process. When it fails, it consistently ends up with an empty LUT being written to the data store used by the update shader, so the particle data samples from zeroed data and its color ends up black with zero alpha.
The Niagara graph compilation process is rather complex, and there are so many layers to it that I haven’t been able to figure out at which point I should expect to see the correct Data Interface referenced. When it fails, there’s always a RapidIterationParameters entry for it in the GPUComputeScript that points to an empty instance of the color curve DI. When set to CPU sim, the correct DI instance data shows up in the CPU update script. Other parts of the code I’ve seen seem to imply that this is not a type that should be a rapid iteration parameter, so I’m not sure if that’s incorrect or just a red herring.
I will keep digging into it, but hopefully someone far more familiar with how this stuff works can provide some insight!