Basic LOD system (mainly for particles)

[[Krogoth86]]

I think it would be a neat thing if there would be a simple "LOD" system that can get set up on the modder's side and focuses mainly on particles (although it might get extended to other areas at some point)...

My idea pretty much looks like this: You get another Detail setting in Spiringsettings saying like Low, Medium and High. You then need a way to pass a variable representing the desired setting into Cob. In the unit's script you then can do stuff like "if ( detail level = 1) do stuff" and "if (detail level =2) do even more stuff"...

So basically it's about calling certain particle effects only at a certain detail level. I think this would be way more powerful than the recent max particle slider as you can entirely deactivate stuff like plane engine FX or Hovercraft water distortions and spawn explosions with a higher / lower particle count...

[lurker]

Now give me a method that doesn't mean there is a desync at the slightest misstep in cob.

[Tobi]

Make CEGs respect particleSaturation for unsynced particles.

Allow modder to set maximum particleSaturation for each type of particle at which it is still emitted, so modder has some control to make e.g. small smoke puffs not emitted when limited on particles, but still emit big particles for e.g. nuke explosions.

EDIT: Alternatively, if CEGs can only emit unsynced particles (doubt that is true but can't check right now), it could be an option to allow modder to define multiple CEGs for different particleSaturation levels.

[[Krogoth86]]

At which point do you see sync problems? I mean reading out a variable and process it in Cob is nothing that unusual and as multiplayer pretty much just is about transferring the given commands the Ceg spawning should happen on every computer seperately depending on their detail setting...

So what do you think does break this? The method I suggested just puts an if function around some emit-fx commands so it should be hard to manage any "missteps" as you call it. At least that's the way I see it...

@Tobi:
So is the particle creation also synced? I thought the whole fx emitting stuff would work on a per player basis and fx spawning commands won't get transferred...

[lurker]

if (detaillevel == 1) turn turret to 0 speed 10000; //oops

cegs are far more synced than they should be, but the solution is not complicating cob.

[[Krogoth86]]

Well of course the if function should be just around the emit-fx commands - should not be too difficult not to let anything else be inside that function...

I suggested the Cob approach for this as I think it's the most simple one. You of course also could like add a tag into the ceg-effect but it wouldn't be as effective and I guess it'd be harder to do...

In the end it's just about assigning different effects to different detail levels so you can entirely deactivate or replace them by versions with less particle count. This especially might be quite something for the newbies which like put the particle count to the max because they think their PC can handle it. As a matter of fact a high particle number can even bring the most modern PC to a crawl rather easy (and so imo the actual max number of particles should be decreased to like 4000 to 5000 maybe with an "Ultra" option that let's you still choose higher numbers. Still on weaker PCs just fiddling around with the max particle number isn't really enough. I for example played for a short time just with my HD3200 Onboard GPU. It actually ran Spring fine and only the complex explosions like that of a Commander made the fps rate drop below 30fps and really brought the game to a crawl. With a detail setting as I suggested there could be inserted leightweight effects from a modder's side pretty much lowering the minimum required system specs...

The most easy thing for this imo still is simply spawning different FX from the Cob level which is rather easy to do...

EDIT:
Another idea: Would it be possible to add another argument to the emit-fx command? So it would be like "emit-fx 1028 from piecename 1" where the "1" stands for the desired detail level and only gets emitted of the global value you set up in Springsettings is the same. Wouldn't need any if functions but "just" engine internal extension of this command...

[lurker]

If cegs respect the limit you don't really need that.

[zerver]

As a matter of fact a high particle number can even bring the most modern PC to a crawl rather easy (and so imo the actual max number of particles should be decreased to like 4000 to 5000 maybe with an "Ultra" option that let's you still choose higher numbers.

Indeed. We also have this other problem with the max particles. When you hit the limit, the nano towers naturally spit out much fewer nano particles. This happens mostly in big games, which tend to run slow. The missing nano particles make the game feel extra super slow. I have hundreds of nanos, but they don't build...? Something wrong with my econ? That is how it feels.

I committed a patch few days ago that helps a bit by not creating those particles that cannot be seen. There are unwanted side effects so I decided to apply this change to the multithreading Spring version only.

[smoth]

I would like a lod to cegs... It would allow me to add little details when the camera is right up on an effect.

[[Krogoth86]]

I committed a patch few days ago that helps a bit by not creating those particles that cannot be seen. There are unwanted side effects so I decided to apply this change to the multithreading Spring version only.

Sounds good. Although I still think the only thing that can enormously speed up stuff here is making the particles calculated by the GPU. Wouldn't be a letdown anyway as they don't interact with the game dynamics and also currently have no need of bouncing off geometry (although even this could be done on the GPU quite easily afaik - well maybe not when interacting with the way Spring handles its stuff)...

In the end it would need a total particle system rewrite and although I think this shouldn't be THAT hard to do it's still a full buttload of work...

[Tobi]

@Tobi:
So is the particle creation also synced? I thought the whole fx emitting stuff would work on a per player basis and fx spawning commands won't get transferred...

No, most particles are unsynced.

There are however particles that are synced. A long time ago I already split them out in multiple directories in the source, but it could use some more changes, e.g. use the current projectilehandler only for synced particles (e.g. bullets, particles that do damage when hitting units), and introduce a new particlehandler only for unsynced particles.

This would also be a first step towards an implementation of new particle engines, which, for example, run on the GPU, or are (hand) optimized to use SSE vector instructions for their math.

Besides that it would probably help zerver much because he would then know only (synced) projectiles can change simulation, and (unsynced) particles can be run quite safely in a dedicated thread, when proper locks are in place when new particles are created.

I committed a patch few days ago that helps a bit by not creating those particles that cannot be seen. There are unwanted side effects so I decided to apply this change to the multithreading Spring version only.

TheMightyOne suggested one time to use a separate particle limit for nano particles.

And wrt side effects, anything more then missing particles on minimap and missing particles when you scroll fast or jump to other location? (F3, click on minimap)

[zerver]

And wrt side effects, anything more then missing particles on minimap and missing particles when you scroll fast or jump to other location? (F3, click on minimap)

None really, except that you may not see particles from units with huge build range (like the long range nano) if the unit itself is just outside camera. But that is easy to fix.

Do you think I should apply these changes to the non-MT version as well?

[Argh]

Um, one thing that's going on with particles right now is that AlwaysVisible tag doesn't seem to work at all, gets treated as useAirLOS. Just thought I'd note that, if anybody's poking at the code and that hasn't been fixed.

[KDR_11k]

Um, one thing that's going on with particles right now is that AlwaysVisible tag doesn't seem to work at all, gets treated as useAirLOS.

Nope, Fibre works fine in 78-2 and that has absolutely no LOS, only alwaysVisible.

[Argh]

Your Units don't have sight radii, or are all Units alwaysVisible? In P.U.R.E., I've done various experiments, and World Builder objects that are supposedly alwaysVisible with effects that are supposedly alwaysVisible don't show until a Unit is right on top of them.

I'll take a look at Fibre when I get the chance, see what the difference is. For now it's just a minor mystery.

[AF]

I think the suggested change to the handlers by tobi should be done, and I also question the wisdom of using cob when talk of lua based scripting abounds. Cob is synced, some particles aren't. Synced operations should use unsynced variables as their basis.

[lurker]

Synced operations should use unsynced variables as their basis.