Hi ,
I think you’ll find that with Niagara, there’ll only be a need to do very few of these things explicitly. It’s a more programmable system (via node graphs) rather than hardcoded functionality. We’ll provide a lot of the features Cascade encapsulates, and much more, via a collection of pre-made graphs and functions, but if something doesn’t exist, there’ll be a clear path on how to implement it yourself. We have some ideas as to how to solve some of the points you mention, but I’ll address a couple in detail:
- The different emitter drawing order within a particle effect has to rather have a natural way of having the sprites that are in front of the others to render on top of them like they naturally should
This is a tricky one, because it involves sorting particles across emitters. Essentially, the way particle systems are drawn (and Niagara is no exception here) is, to create one vertex buffer per emitter (all particles using the same material and, more generally, GPU state), and draw it with a single draw call. If particles from multiple emitters mix spatially and we want them to be properly sorted, we may end up with a draw call per particle, which can end up being really expensive even with low-overhead APIs, considering we may be talking hundreds of thousands of particles. There will be some solutions to that in the form of changing material parameters per-particle and being able to make a single emitter look like multiple materials, but the basic limitation remains. We will continue to explore options, of course.
- CPU particle collision module to be fixed, at the moment collision only works for GPU particles, especially when it comes to once off effects like impacts/explosions.
This is another point we’ll be overhauling completely. At this point it seems likely that particle collisions with scene geometry will be handed off to the engine’s collision system to have unified treatment of the two. One of the advantages is that you’ll be able to get more information out of collision events to use to respond to a collision in your emitter’s update graph(s). Additionally, it’s pretty easy to implement simple collision primitives (spheres, planes, etc.) inside of Niagara, in order to simulate ‘fake’ scene collision with walls, floors, or simple objects; this will be quite a bit faster than full scene collision. Either method should work with GPU or CPU simulation.
- If performance impact caused by overdraw within Effects Materials/Textures can be reduced somehow
There are some ideas floating around in my head about that. There likely won’t be a perfect solution, but we’ll explore a possibility with the option to balance performance vs. quality. How well it’ll work is very much up in the air at this point.
I hope this addresses your questions!
Thanks,