Friday Facts #281 - For a Few Frames More

[MassiveDynamic]

Wow!

Hey is that a squirrel over there?

[Mike Pote]

@posila Forgive me for wondering the obvious, but before you guys went down the turret radius pixel shader rabbit hole, I'm wondering why you don't just render a semi-transparent triangle fan over the map to form a circle for the turret radius? I'm pretty sure you're already doing this for the electricity network visualisation and the car and tank icons. You could use the stencil buffer to prevent overdraw from overlapping radii here too, and it would cut out your pixel shader having to test each and every single pixel on the screen for a radius.

Something like this, but obviously with enough vertexes to look smooth:



I'm guessing you already tried that and it wasn't performant enough?

The middle mesh (I should have written mesh instead of geometry in the blog post, I suppose) is how we always draw it in 0.16 and still in 0.17 until you zoom in close enough onto cluster of turrets and the optimized version kicks in (we use trinagle strip instead of tringle fan because we can batch several circles into single draw call using degenerated triangles) and is what we needed to optimize. Stencil buffer was one of the two ideas we had (and first one we tried out) but it still was not fast enough, so we went to try out the second idea which was drawing geometry procedurally in shader, and were disappointed by its extraordinaly poor performance in some cases ... so we went on to come up with more ideas and essentially ended up combinig the two initial solutions.

Awesome! I knew it would have been carefully considered first and all angles thoroughly tested. Keep up the amazing work!

[Philip017]

Would it be possible to cache the sprite atlases to disk (in some GPU friendly format) after they have been made so that they can be loaded directly the next startup?

Go into the config and change

Code: Select all

; Options: true, false
; cache-sprite-atlas=false

to

Code: Select all

; Options: true, false
cache-sprite-atlas=true

im wondering why this is not true by default, imo it should be... and if there is a problem then it would delete the cache and recreate it. faster loading next time if there are no changes.

also i always play with smoke off as it is too dense, that steam over the reactor setup is too obscuring to be able to work under it, it needs to be half that imo. although the decoratives are ok, i prefer the way it was in 0.13, alot fewer of them, sometimes i just turn them off, especially when they grow through my belts, factories, rails, bricks, concrete, ect.

otherwise great news for 0.17 and i look forward to it! keep up the good work.

[Dixi]

that steam over the reactor setup is too obscuring to be able to work under it

Adds more realism? In RL they usually turn off turbine, before doing some works.

But I agree, less dense smoke will be better.

[Light]

Would it be possible to cache the sprite atlases to disk (in some GPU friendly format) after they have been made so that they can be loaded directly the next startup?

Go into the config and change

Code: Select all

; Options: true, false
; cache-sprite-atlas=false

to

Code: Select all

; Options: true, false
cache-sprite-atlas=true

im wondering why this is not true by default, imo it should be... and if there is a problem then it would delete the cache and recreate it. faster loading next time if there are no changes.

Vanilla without mods loaded in 15 seconds by default and became 7 seconds with the cache enabled. The atlas cache was then created as a 2.38GB file in the Factorio folder.

Enabling my mods it went from 1:37 load time to 1:13. The atlas cache file was 5.94GB.

Those who use mods would need the most improvement compared to the slimmer vanilla. However, given the large file it creates just for a rather lackluster improvement, I'd be hard pressed to recommend that being active by default unless you're getting 5 minute load times (mostly due to sprites) and have an SSD to make the process remotely worthwhile.

[Henry Loenwind]

What I miss in most games is a "test" button in the graphics settings that renders a couple of scenes and reports the fps. Especially in games where the screen starts out empty and fast to render...

[psihius]

I was wondering - we have good decoratives for the grasslands that as it turns out, by accident, make rails look good (or at least interesting), but other surface decorations do not really have anything that can do something similar to the rails. Maybe, if time allows, something similar can be added to other surface types? Like sandbars for dessert, mud for the muddy type surface and so on?
I just looked up the modding API and poked Mylon a bit and want to implement grass growing over the rails with time, but that will work only for those types of surfaces that have appropriate types of foliage. Not gonna be good looking with desert and alike

[Gobbel2000]

What I miss in most games is a "test" button in the graphics settings that renders a couple of scenes and reports the fps. Especially in games where the screen starts out empty and fast to render...

With the cutscene controller announced in FFF #273, it should be easy to create a demanding benchmarking world that can be included by the game as a scenario or downloadable save file. One official map would make performance testing and comparing much easier for players as well as the developers.

[Philip017]

Vanilla without mods loaded in 15 seconds by default and became 7 seconds with the cache enabled. The atlas cache was then created as a 2.38GB file in the Factorio folder.

Enabling my mods it went from 1:37 load time to 1:13. The atlas cache file was 5.94GB.

Those who use mods would need the most improvement compared to the slimmer vanilla. However, given the large file it creates just for a rather lackluster improvement, I'd be hard pressed to recommend that being active by default unless you're getting 5 minute load times (mostly due to sprites) and have an SSD to make the process remotely worthwhile.

vanilla with out mods for me 18 seconds to launch with out cache, with cache 5 seconds.
the file 'atlas-cache.dat' consumes 2.38gb on my drive, located at '%appdata%/factorio' i feel it is easily sacrificed for 13 seconds of launch time.
an option to enable this, in the options menu under graphics, would be nice instead of digging into the config file i never knew about till today.
if this option was enabled by default then more disk space would be used true, however imo most people i doubt they would even notice it missing. but anyone that launches the game repeatably will notice the launch speed difference, if they only knew about it.

[luc]

What I miss in most games is a "test" button in the graphics settings that renders a couple of scenes and reports the fps. Especially in games where the screen starts out empty and fast to render...

Woa, killer idea here!

Why fiddle with the controls and have to figure out specific settings for your GPU, if the game can just try out a few things and give you the option of "optimize for mega base", "balanced", and "optimize for beauty"?

I really like that idea.

[christian]

What I miss in most games is a "test" button in the graphics settings that renders a couple of scenes and reports the fps. Especially in games where the screen starts out empty and fast to render...

Woa, killer idea here!

Why fiddle with the controls and have to figure out specific settings for your GPU, if the game can just try out a few things and give you the option of "optimize for mega base", "balanced", and "optimize for beauty"?

I really like that idea.

Agreed I like that idea

[quyxkh]

Vanilla without mods loaded in 15 seconds by default and became 7 seconds with the cache enabled. The atlas cache was then created as a 2.38GB file in the Factorio folder.

Enabling my mods it went from 1:37 load time to 1:13. The atlas cache file was 5.94GB.

On my HDD box:

cold OS cache, no sprite atlas, seablock, Sprites Loaded at 32.164 sec. Hot cache, 19.923 sec.
cold OS cache, sprite atlas, seablock, Sprites Loaded at 39.854 sec. Hot cache, 13.933 sec.

cold OS cache, no sprite atlas, vanilla, Sprites Loaded at 23.098 sec. Hot cache, 12.269 sec.
cold OS cache, sprite atlas, vanilla, Sprites Loaded at 25.036 sec. Hot cache, 7.110 sec.

Time to read the seablock atlas from disk is 22.5s. The time to decompress a `zstd -1`'d seablock atlas from disk to tmpfs (basically, ram disk) is 6 seconds flat. I'll keep saying it: `zstd -1`ing the atlas caches would get a really dramatic startup-speed boost, even on SSDs.

[code_deamon]

Instead of an off-screen render or passing the list with all turret to the pixel shaders another idea may be to pass the list of turrets in a (macro)tile and pass a tile map to the shader. You can easily create a linked-list of tile on CPU every time someone add/remove a turret.

Because the map is infinite you should limit the tile map to 1024x1024 and use multiple tile maps for huge factories.

[roothorick]

ok so if this gets optimized even more i could probably play it on a Raspberry Pi and take it with me for on the go

We'd need ARM binaries first. I strongly suspect Wube has resorted to inline assembly numerous times, so this would be a substantial undertaking for hardware that would have a very hard time with the game in the first place. (ARM is sloooooooooow! Just for one example, the Switch's SoC is roughly equivalent to a 500Mhz Ivy Bridge era Core i5. Ouchie.)

Now, don't let me dash your dreams. You just need an SBC with an x86 processor, and there's quite a few. The LattePanda is probably the most promising for this application.

[JD-Plays]

Would it be possible to cache the sprite atlases to disk (in some GPU friendly format) after they have been made so that they can be loaded directly the next startup?

Go into the config and change

Code: Select all

; Options: true, false
; cache-sprite-atlas=false

to

Code: Select all

; Options: true, false
cache-sprite-atlas=true

Can we please have that as a toggle option inside the new and improved GUI?

[roothorick]

So what about Linux/UNIX OS optimization? It is similar to Windows and iOS?

Factorio doesn't have an iOS version... I assume you mean OSX? Which is under the Unix umbrella, specifically in the BSD family as a proprietary variant of Darwin, but I digress.

In today's FFF, they wrote off BC7 as unacceptable in part because it isn't supported by OSX. BC3 and BC4 have been implemented on most hardware on Mesa as well as by Nvidia's proprietary driver, so the optimization discussed here can safely be applied unilaterally on Linux systems.

It's my understanding that Linux and OSX are getting a new rendering backend as well based on OpenGL 3.x, I assume core profile, so potentially a huge win. We're not being left out

[func_door]

Am I weird for liking the 'noisy' look of low quality compression?

Gave me Starcraft vibes, must be the nostalgia of compression :p

[Xuerian]

Really enjoyed reading the post, and looking forward to all the performance improvements.

Nothing great to add.

[Acid_Burn9]

Turret range visualization optimized? Great, but look at this!

FPS without logistic network visualization (downscaled to 1440p to reduce size. server doesn't want to accept 16.8MB file)

Снимок экрана (417).png (8.02 MiB) Viewed 8040 times

FPS with logistic network visualization

Снимок экрана (416).png (15 MiB) Viewed 8040 times

Unbelievable FPS drops. Never had them in Factorio before. Happens only in map view, when this button

Снимок экрана (418).png (10.66 KiB) Viewed 8040 times

is turned on (while just hovering above dronestation everything is fine).
That's what really should be optimized lol.

i7-6700K, GTX 1080, 16GB DDR4, win10 64bit

P.S. Thank you for awesome game ^-^

[MicFac]

These results look extremely promising. The highest render time I could find on the "New" benchmark was 22.62ms which would be about 44 FPS whereas with the old build the lowest FPS would be about half that. Although the integrated graphics had the low quality compression enabled, this was with high resolution sprites in a scenario that has extraordinarily much to render.