Friday Facts #326 - Particle emitter & Data cache

[FactorioBot]

Here it is! (beep boop)

https://factorio.com/blog/post/fff-326

[steinio]

Link to the christmas tree mod maybe: https://mods.factorio.com/mod/elka
Holiday Artillery: https://mods.factorio.com/mod/holiday-artillery

First i thought it was Jace, a community manager of Satisfactory in the video.

Loading phase optimisation is all i wanted for christmas, thanks.

[Klonan]

Link to the christmas tree mod maybe: https://mods.factorio.com/mod/elka
Holiday Artillery: https://mods.factorio.com/mod/holiday-artillery

The topic tiles are links to the mod pages

[JekoRhino]

I really like the Particle changes!
It adds so much to the game.

Is there going to be a updated version of the explosion Effect tough?
It looks like a MLG edit with all of the same explosion.
But I really like the explosion, it gives this Factorio feel,
it's just wird to see it multiple times.

Another question:
What about particles that come from Sources(Emitters) off screen?
Say you have Assemblers all around the out side the Red Box(view screen)
and you move in any direction. Will the Particles just appear
or would you see the Assembler exploding when moving there.

Question is based on the Animation where no particles
from out side the Box are rendered or was this
just a example of how it would work.

Have a nice Christmas break everyone!

[Roodvlees]

That's one of the side effects they still need to work on.
I'm mostly wondering about the emitters never moving.
What if there's an emitter on a train?
It seems like this assumption is incorrect.

And no assumptions aren't stupid.
For example; when reading this text you assumed it was about Factorio.
Without assumptions there would have to be a whole book of statements about exactly which context we're talking about.
The problem is when people have different assumptions, that can cause conversations to get stuck.
So when that happens, just take a step back and check your assumptions.

[Allaizn]

What about particles that come from Sources(Emitters) off screen?
Say you have Assemblers all around the out side the Red Box(view screen)
and you move in any direction. Will the Particles just appear
or would you see the Assembler exploding when moving there.

Question is based on the Animation where no particles
from out side the Box are rendered or was this
just a example of how it would work.

I see two separate questions here:
1. How is it handled if an offscreen emitter would be able to create particles that fly into the screen area?
Answer to that is that the emitter is restricted to only create particles up to 16 tiles away from itself. For rendering we then don't use the screen rectangle itself to search for the emitters, but a rectangle that's larger by 16 tiles in each direction (plus some extra to allow account for height).
2. How is it handled if an offscreen emitter comes into view range?
The emitter retroactively creates it's particles and then renders them on the position they should be right now if they would have been created immediately when the assembler exploded.

In other words: particles managed by an emitter and "normal" particles that were defined to look the same should always act the same visually (unless I put a bug in there by accident) - including things like save & reload, going offscreen and onscreen again and zoom-to-map. The only difference is that the emitter's lua definition is somewhat more restrictive than the lua definition for a particle.

Have a nice Christmas break everyone!

Thank you, have a nice time, too!

[Dev-iL]

Happy Chanukah to you too!

[Allaizn]

I'm mostly wondering about the emitters never moving.
What if there's an emitter on a train?
It seems like this assumption is incorrect.

It's not an assumption, but rather a restriction. I wouldn't be surprised if trains would never use emitters as they are now because of that, but that's not a problem. Emitters aren't a replacement for the particle system, they are another way to make particles, with the point being that most particle effects don't need the generality of the full particle system.

And if you're wondering why I decided to not make them movable:
Rendering requires finding all emitters that could potentially draw particles onscreen, which we do by registering them to a spatial data structure (Rseding explained a little about it in FFF 322). Moving emitters would have the need to update this registration over time.
I however jumped through some hoops to make emitters completely update free, so that they'll never directly increase the game's update time (though their creation and destruction does). It's thus mostly not allowed in order to give maximum performance, but while writing this I got an idea on how it's maybe possible to make that work out anyway - we'll see.

[RobertTerwilliger]

It looks quite weird that all the blood drops in water in just 2 waves... (It isn't so obvious when hitting ground) It's WIP, I suppose though : )

[BlueTemplar]

Heh, one time I tried to load the game with 400+ mods, took several hours to fix the mod incompatibility issues in a big part because the data stage took like 20 minutes by itself...
(and then the game crashed in the graphics stage, so I gave up ! )

[_Attila_]

Well, now the bugs certainly die a spectacular death. <g>

[vesoljc]

Regarding the particles offscreen:
what I do, is drop the update rate on offscreen particle systems. At the moment, the drop is fixed (1/10th of update rate), but one could easily make an adaptive solution to save even more updates (drop update more as systems are further away). The trick is that you properly accumulate delta time, and use that value to update the system. The benefit is that system is alive and updating, most importantly, updating it's bounding box, which is used to check if system is visible. Non-visible systems are obviously not rendered and in this case not updated with full update rate.

But few issues arise from such system, which can point out a "faulty" particle system logic, especially with moving emitters. A common logic for particle system is that you accumulate emission value per update and when that emission value reaches >= 1, you emit 1 or more particles. Now, if you have a have high update rate, it looks ok, if you have a low update rate, that emission becomes clustered (if your update is 16ms and spawn rate is matching those 16ms, then you get exactly one particle per update on a moving emitter position, if update rate is 1/10 -> 166ms, then each update you get 10 particles on same spot). The logic fix is that you need to keep previous emitter position and current position, then blend N-spawned particles between those positions according to their spawn time.

Benefit is that this logic also fixes (shitty) frame rate variations. Another benefit comes into play with serialization. You can fast forward particle system to a specific time, by running sequential updates with bigger delta time. So, instead of running 1000 16ms updates, you can run only 50 320ms updates. Then, to save particle system, you only save particle system data link and it's current "play time". On load, create particle system and fast forward to 1.6sec time position.

[Ohz]

Wahou I want those RTS element implemented please ! Minions constently spawning and attacking bitters like in tower defense games!

[Hiladdar]

Optimization of sprites being loaded in to the game, all for that. Optimization of loading mods into the game, all for that.

Regarding delivery of Christmas gifts via artillery. I am OK with that in a mod. Some will like that, some will ignore it. I personally think the most dangerous thing at Christmas is several year old re-gifted fruit cake. I think that fruit cake is a much more potent artillery round then Christmas package. But this brings the real question, for Easter, will we be firing Easter eggs, bunnies, or baskets?

Now back to the serious, multi player on the same map. Say we have 10 players. 9 of them are working on base optimization, with very low, almost non-existent drain on the particles. One of the 9 players is running around tossing nukes, kiting 100's of biters, tossing grenades, dropping poison capsules and mines, while blasting away with either the sub-machine gun or shotgun, in general creating mayhem, to such an extent that their UPS/FPS drops into the 10 range. Oh yes, that bitter killer is also running on a old computer. If the bitter killer is running at 10fps for a long time, eventually they will be out of synchronization with the server.

So some logical first question are?

Will this affect the other nine on-line players, and if so, how?
How will the server synchronize the biter killer up to date with the other players?
Will there be a need for additional server administration tools to mitigate that, and if so what will those tools be?

Hiladdar

[Oktokolo]

I would like the new particle system being usable for moving sources (trains, biters, damaged bots...) too.
Each particle would need a spawn offset from the (still immobile) emitter and emitters would have to be created all few tiles of movement of the source. But it should still perform way better than faking a particle system using entities...

[Impatient]

I definitely like this: " ... millions of biters dying in gigantic blood fountains offscreen would thus basically not matter at all for your frame and update time!"

After I understood what you are saying, I immediately wondered what else the engine is calculating every tick for visual purposes only. Flamethrower stream parts? Projectiles? Inserter arm positions? Basically any movement that has a starting time, which's path follows a known mathematical function and which can not be affected by another entity.
If so, can position calculations between shot and impact or inserter pick-up and drop-off (or drop-off and pick-up) be ommited if the movement happens off screen?

[Oktokolo]

Inserter arm positions?

Inserter arm position change speed depends on availability of electricity or fuel.

[BlueTemplar]

Neither of these is visual only since they have in-game consequences...

[Allaizn]

After I understood what you are saying, I immediately wondered what else the engine is calculating every tick for visual purposes only. Flamethrower stream parts? Projectiles? Inserter arm positions? Basically any movement that has a starting time, which's path follows a known mathematical function and which can not be affected by another entity.
If so, can position calculations between shot and impact or inserter pick-up and drop-off (or drop-off and pick-up) be ommited if the movement happens off screen?

I have been wondering about this question since I got source access (which happens to be exactly one year ago tomorrow). The basic answer is that there are a lot of things, and that most of them cannot be skipped - mostly because there is some way for mods to read and/or change that value, which basically forces it to always be existant and correct.
It's one of my personal quests to find and vanquish as many of those as possible

[Philip017]

i have a couple of things about the particles, i should share that i don't particularly like them (personal preference)

1. can i disable them, because they aren't for me or because i use a potato pc?
2. imo, particles are triggered, they go off, but aren't saved to the game state, if you save right after they are triggered, upon loading the game again it will be as if the event never happened, ie the end result after the whole effect finished would be the saved game state.
3. they should not effect anyone else's game state, if i enter the frame after the event triggered imo it should either show the particle start, or end result, not having to have to show states in between, the effect only lasts for a second or two anyway so i don't see the point.


caching of data

i began using the shader cache option once i learned of it's existence, i recommended then and recommend again that this be an option in the menu system somewhere, instead of a 'hack' that you have to do manually in a config file. i personally find it cutting my loading times down such significantly that the loss of a few gigabytes on my drive to be a very easy decision to make. i hope that the new cache option will also be helpful in such a way as well.

thanks for all the great work you do on the game!