PB4b Suggestion: MaxParticles Control

[Steeveeo]

While attempting to make a realistic cloud system for the SRV campaign, I ran into a major issue that kept it from working entirely.

PB4a only caches enough particles for ONE of each effect, explosion, render, or otherwise. That is, when the effect is played again, the spawned particles cause the old ones to disappear, as if overriding the old particles.

Its kind of a hard thing to explain, but let me try this: My effect uses 5 particles per emit, at 0.2 second delays for 1 second, waiting 5 second before the next emit. I can see each particle of the last emit clip out one particle at a time while the next one goes.

What I am asking is thus: an ODF maxParticles command for things like Draw_emit, Draw_twirl, Draw_twirl_trail, and/or the particle declarations of explosions, along with whatever else needs it.

This would be extremely useful for explosions that use after-effects like SRV's char smoke, which, after multiple vehicles have blown up, cause the effect to clip closer and closer to the origin, looking awful.

Not only could this be used to increase the time before particles get clipped (and adversely increase framerate drop), but it could be used to limit more intense explosions and effects from lagging down older comps (reducing the aforementioned FPS drop).

Thanks in advance, this would help a figurative ton with making more dynamic effects in mods.

[Commando]

You may need to provide some demo effects to show us what you are talking about.

[Steeveeo]

Get SRV, blow up one scout, look at the after effects (char on ground, slight smoke rising).

Blow up 2-5 scouts, observe same after effects. The slight rising smoke gets cut off, and more so as the numbers build.

It doesn't matter how many particles I have in the columns, it cuts off just about the same.

A similar effect can be seen with the dust trails of the units.

[Nielk1]

A better demo would be... a small zip with a save and a few assets in it that you open and do something or look at something and watch. Taking the sum total of 5 seconds.

[bigbadbogie]

Particle culling is probably the one thing keeping the framerate up Steeveeo.

Are you sure this is a good idea?

[Steeveeo]

Particle culling is probably the one thing keeping the framerate up Steeveeo.

Are you sure this is a good idea?

Please read what I write, don't just skim.

[bigbadbogie]

I did read it. Just not today. 

Anyway, the particle culling system probably culls them from every single effect. By adjusting one effect you could easily throw another one off balance and therefore every effect would need this to be included and adjusted perfectly, which is a lot more work.

[TheJamsh]

i asked GSH for some adjustments about particle culling and he shot them down pretty quickly. i can see why too, i bet its no easy task getting down and dirty with the graphics code to that extent.

apparently adjusting such features can have very strange effects on other FX going on in the distance and suchlike. cant reemember the entire conversation.

[Angstromicus]

The way the particle culling system works is on a effect by effect basis.

There is a max particle count for all instances of mywep.odf -> [twirltrail] in the game world.

BUT, there is also a max particle count for all instances of mywep.odf -> [twirltrail2] in the game world.

So if the limit is 1024 particles in a twirltrail render, then you could have up to 2048 particles between those two renders.

[Zero Angel]

I think that something like particleCullExclude = 1 -- you know to prevent the particles from being counted by the engine. Allowing you to therefore hammer on an unsuspecting player's framerate.

The other solution would be to make your effects more efficient somehow, by experimenting with emit delays and such.

[Steeveeo]

As I said before, it does not matter how many particles I tell it to use, it could be a max of 1-2 particles per second on a ten second render, or 25 particles in an explosion, the PB4a engine seems to take the number of particles that will be used by one instance, and use that for a limiter for all instances.

@particleCullExclude: I'd still like to limit the max number of particles, rather than just unlimiting them. Example, in SRV, it would be nice to have decent kickup trails for longer, but if I dont limit them at SOME point, the game will go bonkers.

[Zero Angel]

Oh, I see what you're saying.

Kickup trails are cool by the way. BZ2 has built in HP types that you can attach to your model to draw these renders automatically. Something like hp_spray_l and hp_spray_r.

Another suggestion re: kickup trails is to use something much simpler. For example a repeated "draw_planar" on the ground would also produce some effects simulating dust being pushed about from the hover technology. This would only draw one thing per craft (or maybe two if you used overlapping draw_planar). The only downside to this method is that since it draws the texture flat upon the ground, it doesnt have as 3D'ish of a look as draw_smoke.

[TheJamsh]

ive noticed that layered planars have a hell of a hit on the BZ2 engine. i dont like to keep two layered over one another for too long.