Particle Optimization Issues

[Snipawolf]

I'll practically be copying this straight from the chat I had with Neddie.

I have an issue, and it is more or less a bug, rather than a feature request. I believe I know why certain FX is not showing. Occasionally, the caterpillars groundflash and spikes do not show. This is not an issue with most other units.

I believe the issue lies in springs "optimization" of particle usage. If the caterpillar is really close, and the arm is too far in the unit, it doesn't show a LOT more often. Maybe because of the hitsphere, or perhaps because it is hiding behind polygons, either way, it needs to be changed.

Also, I have noticed that smoketrails on missiles are not rendered when the model of the unit is in the way. Another optimization issue, because I see a missile without a trail.

Although, I can hope someone will fix this (Why hasn't anybody ever questioned it before?), I doubt anyone will do anything, regardless of where I put it. -__-

[Argh]

+1

I'm having multiple problems like this, with FX. Lots of things I want to do, to lower my total particle count would require purposefully over-drawing stuff- using a few large particles doing various things to make very complex FX.

CSphereParticleSpawner, which used to have a Z-order fix (it checked Z-order, whereas CSimpleParticleSystem did not, originally)... has been combined by CSimpleParticleSystem by somebody in a past commit, so I can't do this- all Spring particle systems seem to be doing some sort of culling based on z-order now.

This sucks. First off, it sucks because particles should ignore Z-order by default- it's a lot faster. Secondly, it sucks because it's not a choice. Thirdly, it sucks because it severely reduces my options.

The maddening thing about it, is that it's NOT CONSISTENT. For example, you cannot "stack" two BitmapMuzzleFlames on the same vector and origin. Multiple vectors draw just fine.

If you have a CSimpleParticleSystem and a CSimpleGroundFlash of exactly the same size, then the CSimpleParticleSystem refuses to draw, or only draws some of the time- and does not behave properly, additive-wise. But, if you have a CSimpleGroundFlash and multiple small CSimpleParticleSystems flying about, it all renders correctly, including the additive!

Why this culling behavior is happening, I dunno. Why it's not consistent, I dunno. Why it seems to rear its ugly head the most when two particles share an origin and vector... I dunno. But it's really irritating, because I came up with several things that could make particle systems a lot "lighter weight" in terms of cost... and they don't work because of the rendering problems

[Tobi]

Due to the used blending mode, the painter's algorithm (Z sorting) is needed because drawing order matters.

As far as I know there is no culling of particles of a particle system that is entirely on screen, it would be way too CPU intensive to do so. It may be that entire particle systems are culled if they are off screen, but I'm not sure of that.

I can imagine it looks like culling due to the alpha values used in the textures and some Z conflicts.

For example because first projectiles are sorted on Z and then the particles in each projectile are sorted on Z separately:

Consider you have 2 particles systems:

-> ,,,,,A,,,,, .....B.....

(A and B are the origins and , and . the particles of resp. A and B. The arrow represents the viewing direction)

Now when they are close together you want the particles to interleave:

-> ,,,,,A,.,.,.,.,.B.....

But because A and B are projectiles and are sorted in the projectile list, and all .'s are only sorted in a the list with all other . you'll get this:

-> ,,,,,A,,,,,.....B.....

Then if A and B get very close together the high level Z order may change:

-> .....B.....,,,,,A,,,,,

So even .'s that should be behind A are rendered in front of A.

[KDR_11k]

The render mode isn't optimal for most things so the rest doesn't have to be optimal for the render mode at all times. When we do additive particles the Z-order does not matter.

[Mr.Frumious]

I get the impression that the problem isn't culling, but that, if you have 2 particles that are coincident in space, only one is rendered, am I right Argh?

As for z-order, I think the point is that Argh and KDR want "clustered" particles. That is, "all of these particles have the same Z order, sort them as a single block instead of individually and then just render them in order of creation" or something like that, am I right?

Then a smoke-cluster would be either entirely-invisible or entirely-visible.


Also, I'm curious about something with a very isoteric application in space games - is there a way to render a billboard coincident with a 3D object, but z-order-wise behind everything? That is, to have an in-game object bear a halo that appears to be on the skybox (at least in 2d - if viewed with a 3d renderer the depth would be at the object's level)?

[Tobi]

I get the impression that the problem isn't culling, but that, if you have 2 particles that are coincident in space, only one is rendered, am I right Argh?

That IS culling.

If something is not rendered, for whatever reason, it is apparently being culled. Doesn't matter whether it's backface culling, some more complex hidden surface removal or just coincident particle culling

As for z-order, I think the point is that Argh and KDR want "clustered" particles. That is, "all of these particles have the same Z order, sort them as a single block instead of individually and then just render them in order of creation" or something like that, am I right?

That would only look good for 100% additive blending...

Then a smoke-cluster would be either entirely-invisible or entirely-visible.

...which looks horrible with smoke.

Also, I'm curious about something with a very isoteric application in space games - is there a way to render a billboard coincident with a 3D object, but z-order-wise behind everything? That is, to have an in-game object bear a halo that appears to be on the skybox (at least in 2d - if viewed with a 3d renderer the depth would be at the object's level)?

Yes that is doable. One way would be to disable the zbuffer, first render those billboards and then render all other stuff (with zbuffer enabled) on top of them.

[KDR_11k]

I get the impression that the problem isn't culling, but that, if you have 2 particles that are coincident in space, only one is rendered, am I right Argh?

As for z-order, I think the point is that Argh and KDR want "clustered" particles. That is, "all of these particles have the same Z order, sort them as a single block instead of individually and then just render them in order of creation" or something like that, am I right?

Then a smoke-cluster would be either entirely-invisible or entirely-visible.


Also, I'm curious about something with a very isoteric application in space games - is there a way to render a billboard coincident with a 3D object, but z-order-wise behind everything? That is, to have an in-game object bear a halo that appears to be on the skybox (at least in 2d - if viewed with a 3d renderer the depth would be at the object's level)?

No, I just want a "draw additive" option that completely removes the alpha darkening and can consequently just not write to the Z-buffer, provided it's drawn after the solid things. Half of my particles are meant to be additive anyway and only contain alpha because a particle with 0 alpha is not drawn.