I’ve been experimenting with Niagara Data channels and I had some questions related to best practices.
Here is a hypothetical example:
If you would have multiple weapon impact effects, which vary based on weapon type and physical surface of the impact area (and each impact carries a number of different emitters, dust, debris etc).
What would be the best approach to tie this into a data channel setup? It seems overkill having to load in all the different weapon impacts by adding it into the system array within a single data channel (island mode). In this case every Niagara system would get loaded even when it isn’t spawning any particles in the emitter by using a conditional. The Niagara systems will still get activated and cause a base overhead.
Creating an Uber Niagara system with tons of emitters in it and different conditions, would create the same issue in terms of overhead.
Creating a different data channel for each separate weapon impact/Niagara system also seems overkill, as you would be passing along the exact same data each time in many different data channels: impact location, surface orientation etc.
Ideally you would be able to set up one data channel that is of the same type which reads the same data (e.g. impacts) with all your Niagara systems in it and set up a condition there to decide which Niagara system should get placed, before it spawns in the Niagara system and triggers the particles, instead of using a condition on the emitter where everything already has to get loaded. But perhaps I am missing something and this is already possible?
So the main parts of the implementation here would be.
1. New custom NDC type that can internally store different FNiagaraDataChannelData.
Similar to how the Islands data channel does it but in your case you’d want to split these up by spatial location and physical surface etc or however else you’d like.
See UNiagaraDataChannelHandler_Islands::FindData().
2. A component type that would allow access to this surface data.
We currently use FNiagaraDataChannelSearchParameters to pass in the location data that we use to find which NDC Island we will pass the data into.
Ideally this would be more flexible and allow us to pass in whatever data the NDC needed to do it’s internal routing. In your case a surface type.
This is what I’m working to improve currently. Until this is available, there is also a Component ptr passed in.
The Islands NDC only uses this component to take it’s location.
However, with your own custom NDC type you could use this component to get the correct surface type for the current FindData() call.
You could pass in a custom component or you could possibly hijack the ComponentTags?
Great to hear you are looking to improve the current implementation.
Can’t wait to see those improvements in action! In the meantime our engineer internally is very interested to see the current workaround you mentioned, which requires custom code.
We’re curious to hear more on the implementation of this.