Requests for next iteration of Cascade

[anonymous_user_405b8cdf1 (anonymous_user_405b8cdf)]

Ive heard you guys are developing something like Cascade 2.0 or Niagara?

If so, here are my main requests for improvement in areas i,ve been having lots of hindrances:

• UV Image flipbook modules cannot see to work well with the Interpolation Module options in the sense that only Linear/Linear Blend seems to work along the Sub Image index/SubUV move modules, other options like Random/Random Blend are not randomizing my starting frames at all nor work in general, making me wonder why are they there as options. Both CPU and GPU particles fail to display random starting frames within a Sub UV texture. This random starting frame setting, for example, is crucial for spawning random debris pieces within one emitter and one texture (SubUV flipbook with random debris in each frame).

• being able to do more size/size over time modifications to both cpu and gpu particles in terms of x y z values.

• a simplified and effective color/color over life function that could make you choose colors from a palette rather than playing with curves.

• To be able to randomize lighter/darker tones of a specific color (like brown). At the moment its very complicated and un-intuitive to achieve that :(.

• 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, rather than having them being rendered left=bottom right=top from the emitter list layout. This, at least in my experience, causes you have to create many emitters one after the next in order to have them being rendered both behind and in front of other background sprites, like in the case of flying GPU debris or a dust/smoke shockwave, and even still i wont get a genuine effect due to this render order method. Also, i wouldn’t know why we have a “sort order” option in within the required module? seems completely useless at the moment?

• 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.

• If performance impact caused by overdraw within Effects Materials/Textures can be reduced somehow that will be fantastic, at the moment its hard to make effects that wont have any performance impact even with fairly simple sprites. The vegetation artists in my team are also having a very hard time with Vegetation overdraw and they said that solutions are coming in the near future for that area, just hope effects can get an improvement also.

Please let me know, if feasible, about the improvements that the next iterations of Cascade are mainly gonna be, and maybe if this areas are being revised for improvement.

Thank you very much!

[anonymous_user_a5f8060f]

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,