Friday Facts #326 - Particle emitter & Data cache

Regular reports on Factorio development.
User avatar
FactorioBot
Factorio Staff
Factorio Staff
Posts: 403
Joined: Tue May 12, 2015 1:48 pm

Friday Facts #326 - Particle emitter & Data cache

Post by FactorioBot »


User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2631
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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.
Image

Transport Belt Repair Man

View unread Posts

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 5147
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Klonan »

steinio wrote: ↑
Fri Dec 20, 2019 2:50 pm
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 :D

JekoRhino
Inserter
Inserter
Posts: 22
Joined: Wed Jan 09, 2019 12:02 am
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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
Burner Inserter
Burner Inserter
Posts: 17
Joined: Sat Sep 15, 2018 11:50 am
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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
Former Staff
Former Staff
Posts: 90
Joined: Sat Mar 03, 2018 12:07 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Allaizn »

JekoRhino wrote: ↑
Fri Dec 20, 2019 3:14 pm
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.
JekoRhino wrote: ↑
Fri Dec 20, 2019 3:14 pm
Have a nice Christmas break everyone!
Thank you, have a nice time, too!

User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 298
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Dev-iL »

Happy Chanukah to you too!
Leading Hebrew translator of Factorio.

Allaizn
Former Staff
Former Staff
Posts: 90
Joined: Sat Mar 03, 2018 12:07 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Allaizn »

Roodvlees wrote: ↑
Fri Dec 20, 2019 3:24 pm
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
Fast Inserter
Fast Inserter
Posts: 196
Joined: Wed Nov 18, 2015 10:12 am
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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 : )
Holding formation further and further,
Millions of lamb stay in embrace of Judas.
They just need some bread and faith in themselves,
BUT
THE TSAR IS GIVEN TO THEM IN EXCHANGE!
Original: 5diez - "Π˜Ρ‰Ρƒ, тСряя" (rus, 2013)

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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 ! :lol: )
BobDiggity (mod-scenario-pack)

User avatar
_Attila_
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Sun Jan 06, 2019 2:46 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by _Attila_ »

Well, now the bugs certainly die a spectacular death. <g>
Attila's QuickBar Mod - Auto-links hand crafted item to first free quickbar slot if not already linked.
Attila's Signals Mod - Alternate signals to use in same circuit as standard signals.
Attila's Zoom Mod - Modifies zoom functionality.

vesoljc
Burner Inserter
Burner Inserter
Posts: 10
Joined: Fri Dec 20, 2019 6:53 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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.

User avatar
Ohz
Fast Inserter
Fast Inserter
Posts: 187
Joined: Tue Feb 03, 2015 11:40 am
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Ohz »

Wahou I want those RTS element implemented please ! Minions constently spawning and attacking bitters like in tower defense games!
I'm not english, sorry for my mistakes

Hiladdar
Fast Inserter
Fast Inserter
Posts: 214
Joined: Mon May 14, 2018 6:47 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 883
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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...

User avatar
Impatient
Filter Inserter
Filter Inserter
Posts: 880
Joined: Sun Mar 20, 2016 2:51 am
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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?

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 883
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Oktokolo »

Impatient wrote: ↑
Fri Dec 20, 2019 10:27 pm
Inserter arm positions?
Inserter arm position change speed depends on availability of electricity or fuel.

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by BlueTemplar »

Neither of these is visual only since they have in-game consequences...
BobDiggity (mod-scenario-pack)

Allaizn
Former Staff
Former Staff
Posts: 90
Joined: Sat Mar 03, 2018 12:07 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by Allaizn »

Impatient wrote: ↑
Fri Dec 20, 2019 10:27 pm
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 :)

User avatar
Philip017
Filter Inserter
Filter Inserter
Posts: 355
Joined: Thu Sep 01, 2016 11:21 pm
Contact:

Re: Friday Facts #326 - Particle emitter & Data cache

Post by 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!

Post Reply

Return to β€œNews”