Cascade: Spawn Set # of Particles with Loc. Distribution

Hey all,
I am trying to spawn 12 mesh particles with an infinite lifetime and distribute them evenly between two points, I have managed to get it all working except for two things:

  1. The particles do not evenly distribute, it would seem some of the particles overlap and end up leaving gaps
  2. I can not get a set number of particles to spawn

Would someone be able to tell me how to spawn a set number of particles (12) that spawn immediately, and last forever? And perhaps explain how to get them to actually evenly distribute between the two points?

In the initial location settings, I have them some what properly distributing by using the Distribute Over NPoints, which states it evenly distributes them, but it is leaving gaps.

Thank you for any help

Is it for a mobile game or other non-mobile platforms? or both? Draw count becomes higher for mobile due to a different calculation of it compared to non-mobile draw calls calculation. Here’s a link for VFX optimization that describes it:

It’s also dependent on the number of passes for the material of the particle, with 1 draw call per pass. So if the material requires 2 passes, and it’s in a mesh emitter (1 emitter only in Cascade) of 12 particles (or meshes), then it’s 2 draw calls. In mobile, it would be 1 draw call per mesh emitted, so 24.

Particle Burst Method might also be necessary to change from Instant to another type. Most of the settings in the screenshot look correct, otherwise.

Nice info and thanks for link, will check this out. All I knew about draw calls was each material was a draw call and each mesh was a draw call. Will be nice to take a closer look at this info. It is for non-mobile, but plan on optimizing for mobile until I hit a point where I have to use a feature that is non-mobile only. How do you tell how many passes a material is? I only know that it tells me these stats:

294687-material-stats.jpg

So, non-mobile, seems like getting the emitter to work would be really nice for performance possibly, although the child actor method makes it super easy to reuse the flames for other actors with different meshes/spaceships.

Oh, right now material using a noise node, but that will be replaced with a texture of what the noise node is producing.

This is in the Getting Results part of the VFS Optimization Guide:

“Draw calls for a particular scene can be viewed using the command DumpParticleFrameRenderingStats. This command outputs a spreadsheet which lists draw call costs in detail.”

So, typing ` and then DumpParticleFrameRenderingStats into the console. Try it in the specific material being used rather than in the particle editor, so in the material editor for the material that the flame mesh is using. Then use it in the particle editor to see the totality of the system thus far. I noticed that when I used the Mesh TypeData, and am using a more basic mesh (a 2d circle), that decreasing the MaxDrawCount to 1 or 2 only spawns 1 or 2 of those circles at a time. Setting it to 12, however, seems to spawn more than 12. I too am having difficulty getting the meshes, or particles (without using Mesh TypeData) to spawn simultaneously along a vector of length 120 and z-offset of 30. The vector they spawn along is accurate, and the spacing from one mesh / particle to another is evenly distributed. But they spawn randomly across it, with temporary gaps depending on where other particles are spawning currently. It’s really weird, and I was thinking after reading about LifeTime that it has something to do with MaxDrawCount (12), spawn rate (12), and lifetime. It appears that when the 12 particles spawn, at least one or a few spawn over an occupied point in the distribution, and at different times. So as the MaxDrawCount is reached, or the spawn rate is reached, both 12, gaps are left until one or more disappears due to its lifetime ending.

The trick is going to be getting one particle to spawn at every point along the distribution (all 12 meshes / particles, one per point) simultaneously, and either constantly looping or staying there rendered until the thrust input is applied. Then the thrust results in flame increase / expansion, and release of it doesn’t kill the particle / mesh entirely.

Yip, exactly. The MaxDrawCount only controls how many particles are rendered, not spawned, so more will spawn but not be rendered. You are now where I am in terms of trying to figure out how to spawn an exact number of partcles, get hem to spawn (not random) on an evenly distributed NPoint. Giving the particles an infinite lifetime is easy. The next part would be to via blueprints and an event dispatcher, update the scale of all the particles and alter their material prameters. I know the material should be easy, i think, but not sure if scale can be altered via blueprints or only by lifetime of particle etc. I have not gotten into Niagara, but what little I know, I would think this would be very possible with Niagara as it has sooo much more data driven potential. And again, depending on performance gain, might be better any ways to use child actor method for eae of setup and reuse, cause using an emitter, I would have to create 3 emitters (each wing) and use child actors for the forward/reverse thrust. And then…I would have to create new emitters for each type of spaceship. So, in the end, unless the performance was a big enough gain, or I was spawning 1000 spaceships for a small gain to make a difference, seems to me the child actor is the way to go?

The particle emitter approach would be quite a bit more efficient in terms of rendering for larger numbers of spaceships. But that depends on other settings too. Either method is probably efficient enough, but I thought particle fx would be easier to modify quickly and without having to construct multiple blueprints to spawn various shape flames and their effects. Because it relies on material instancing AND the ability to create the effects in a run-time type of preview in Cascade. Whereas blueprints requires then placing the assets in the level and seeing how they’re working. Niagara might be better for it. I’m new to these things too, so I’m basing my suggestion and insight on mostly what I’ve read so far.

What’s your game’s premise / format, basically? Is it a 3rd person space shooter, or a different one?

2.5D Side-Scroll Space Shooter - think Gradius or R-Type