[FEATURE] VRAM requirement is not sane

[sthalik]

Hey,

This is a continuation of my rejected previous feature request, with a better-formulated proposal. I'll drop the issue and won't pester you about it if you reject this one as well.

Please "do something" with high VRAM requirements for 0.17. Let it run without constant thrashing on a 1 GB VRAM card or below. The VRAM requirement is very steep even considering the amount of sprites. Without mods, 2GB VRAM won't work with high detail sprites. It's also unusable with medium-detail Alien Biomes. Medium quality sprites (like steam engine) look bad when zoomed in. The Alien Biomes mod is too tasty to pass. Lossy artifacts are negligible with a high pixel density display. Please don't remove the unsupported compression option

I can point out several things you know already. Maybe we could discuss that with other users? You're the codebase and render experts, please don't take this as patronizing.
- can estimate own VRAM load vs capacity, then unload and lazy reupload into different atlases to avoid thrashing (use atlases as a dynamic MRU list; blitting to promote/demote between atlases is cheap since it's done inside VRAM)
- could ship pre-compressed ASTC image assets for no DXTn artifacts
- can allow the atlas cache to save pre-compressed textures (glCompressedTexImage2D, upload etc.) for reduced load time

As a rationale, please note:

- the GPU price crisis (my 270x still costs as much as it did years ago)
- not having a gaming rig, avoiding AAA manshooters
- Factorio's not like a flight sim or an open-world game modded with excessive detail assets
- the oblique projection is completely dense, not like isometric that's more wasteful–old RPGs like Fallout or Arcanum had tons of sprites and 5-6 Hz animations, with small RAM requirements

Relevant PC specs:

CPU–Intel 7600 (4-way Kaby Lake up to 4 GHz boost)
RAM–32 GB
GPU–Radeon 270x with 2GB VRAM; standard AMD driver for Windows 10

[Rseding91]

Moved to ideas and suggestions.

[Jap2.0]

2GB VRAM works fine for me on high detail sprites. I even got 1GB to work fairly well on semi-high quality in 0.15.

[Zavian]

My GPU only has 1 Gb. Factorio runs fine on normal resolution. Would Hi-Res textures look better? I'm sure they would, but even if I had the ram, my gpu probably doesn't have enough fill rate to cope with 4x the pixels. Also form what I read a month ago it looks like gpu demand for mining is finally dropping so hopefully price will drop as well.

[Jap2.0]

My GPU only has 1 Gb. Factorio runs fine on normal resolution. Would Hi-Res textures look better? I'm sure they would, but even if I had the ram, my gpu probably doesn't have enough fill rate to cope with 4x the pixels. Also form what I read a month ago it looks like gpu demand for mining is finally dropping so hopefully price will drop as well.

Yeah, with the additional added high quality textures, 1 GB is probably a stretch, especially if you don't have a good amount of RAM. GPUs are finally settling back down to semi-reasonable prices, although I've heard that RAM prices are going crazy now.

[bobingabout]

Honestly, I think pre-loading all graphics is a crazy idea...

I remember going back to RA2 on my laptop. now, when I install RA2, I always used to copy the .mix files from the CD to the install directory, which lets the game load all the assets from the hard drive instead of the CD, no issues at all. But when I was running it on my laptop, due to the smaller hard drive, I didn't do that.

I was stunned to see that every now and then, when you built a new structure you hadn't built before, or moving over to an enemy base who had built something you'd not seen before, the game would freeze for a moment as the CD spun up, and loaded the assets.


Considering I'm running on a WD Black, and SSD is an option for me, Loading graphics on demand as they're needed, and unloading others when they're not is something I would consider acceptable, especially when running on lower spec hardware.

I mean, you already have a sprite map to show what is currently on screen, what would the difference be from populating that sprite map from the HDD, or populating it from cached sprites in VRAM?
Especially when you're in the middle of a total graphics re-write, NOW is the time to consider such things!

Seriously, I was trying to run the game at work, and the computers aren't even particularly old, they're just workstations, so don't have much in the way of graphics, and the limited VRAM prevented me from running the game. I managed to get it to run on absolute minimum settings after manually editing the config file. It looked crap.

[bobucles]

There are definitely better ways to reduce VRAM requirements. Reducing animation frames, removing excess tree sprites, simplifying terrain, reducing train rotations, things like that. Factorio does not need 300 different types of tree to be Factorio, after all. Turning the world into a censored pixel blob is probably the worst solution.

[posila]

There are definitely better ways to reduce VRAM requirements. Reducing animation frames, removing excess tree sprites, simplifying terrain, reducing train rotations, things like that. Factorio does not need 300 different types of tree to be Factorio, after all. Turning the world into a censored pixel blob is probably the worst solution.

I agree, I'd like to change what effect low and very-low graphics quality options have, to do what you have said, instead of downscaling everything. I've started to experiment with that in 0.16 already by adding "Low quality sprite rotations" option, which makes the game skip half of the rotation sprites of train related entities

Please "do something" with high VRAM requirements for 0.17. Let it run without constant thrashing on a 1 GB VRAM card or below. The VRAM requirement is very steep even considering the amount of sprites. Without mods, 2GB VRAM won't work with high detail sprites. It's also unusable with medium-detail Alien Biomes. Medium quality sprites (like steam engine) look bad when zoomed in. The Alien Biomes mod is too tasty to pass. Lossy artifacts are negligible with a high pixel density display. Please don't remove the unsupported compression option

One of the motivations for rendering overhaul is to "do something with high VRAM requirements for 0.17". I am extremely careful from making any promises yet, though.
(Btw. ASTC is compression supported by lot of mobile GPU's, but on PC it is available only on Intel HD on Skylake CPU's or newer - no AMD nor nVidia desktop GPU supports it)

...

If you enable "Low VRAM mode" and set "Video memory usage" to low, the game will still preload all the sprites, but most of them only to RAM. So the most of sprites will be copied to VRAM only when needed.
Anyway, what I wonder every day about, and what I was gonna ask here on the forum one day - how much harder would it be for modders, if the game required sprites to be preprocessed somehow, and if the vanilla assets were distributed in the preprocessed form (something like Red Alert's mix files) instead of individual sprite sheets in PNGs? It's one of my big concerns for when we will do changes to how the game handles its assets.

[Deadlock989]

Anyway, what I wonder every day about, and what I was gonna ask here on the forum one day - how much harder would it be for modders, if the game required sprites to be preprocessed somehow, and if the vanilla assets were distributed in the preprocessed form (something like Red Alert's mix files) instead of individual sprite sheets in PNGs? It's one of my big concerns for when we will do changes to how the game handles its assets.

Without more detail, I can't say "how much harder" - but it sounds like added hassle, i.e. somewhat harder. I wouldn't be wild about it, especially if it were only improving things for the minority of players who need to use a gaming potato. My PC is only mid-range with a slightly-better-than-mid-range GPU and I've never seen the game run under 60 FPS. But I wouldn't expect that on hardware which was never intended for gaming.

As someone new to modding and 3D graphics and sprite sheets, I already find it very time consuming and difficult preparing graphics, in fact it already turned out to be more effort than I actually have time for. If there were some kind of ready-made conversion tool available that did the work for me, it might not put me off so much.

[bobingabout]

Anyway, what I wonder every day about, and what I was gonna ask here on the forum one day - how much harder would it be for modders, if the game required sprites to be preprocessed somehow, and if the vanilla assets were distributed in the preprocessed form (something like Red Alert's mix files) instead of individual sprite sheets in PNGs? It's one of my big concerns for when we will do changes to how the game handles its assets.

Well, I modded red alert 2, so if you provided the original PNGs somehow for modders, or a method to extract them from the factorio compressed format, along with tools to convert graphics to the mod format, then I'd be fine with that.

Hell, just put the entire mod, all files, in some sort of archive, so you just drag and drop a pre-built file into the mods folder and go, so basically it replaces the zipping process.

I would request though, that for modding sake, you still allow compatibility with how things are now. It's very convenient to just have everything you're working on in a mod folder, and have the game be able to read it, then just zip it up when you're done.


That's my thoughts on it anyway.

[eradicator]

If you enable "Low VRAM mode" and set "Video memory usage" to low, the game will still preload all the sprites, but most of them only to RAM. So the most of sprites will be copied to VRAM only when needed.
Anyway, what I wonder every day about, and what I was gonna ask here on the forum one day - how much harder would it be for modders, if the game required sprites to be preprocessed somehow, and if the vanilla assets were distributed in the preprocessed form (something like Red Alert's mix files) instead of individual sprite sheets in PNGs? It's one of my big concerns for when we will do changes to how the game handles its assets.

From what i've seen time and time again on the forum, making sprite sheets from individual pngs is already a major hurdle, especially because no factorio-specific tools for them exists and everyone has to fiddle something together on their own. I personally don't have a problem with learning more about image magick...not everyone might share that feeling. So, if you would replace the need to make a sprite sheet with the need to make...some other format, and provide an official tool to create that format from a bunch of pngs, then you would probably end up with a hurdle that is lower than it is now. If the need to care for "one sheet can't be bigger than 2048x2048" (i have some pretty large animated things that require several sheets to fit) vanishes along with that because the tool handles that automatically, even better. If you openly document the format the community might even make some nice tools on its own.
Dynamic loading would also be especially nice for use on temporary animations, e.g. a large script-triggered explosion, because currently something like that would permanently steal VRAM even if it was only used every few hours (i have a few other concepts that would greatly benefit from not having to consider the VRAM usage of such temporary things).
Though i agree with bob that it would be preferable to have a way to run mods directly from folders for development (cli switch that autogenerates the blob on launch?). If the preprocessing of the files is an irreversible process some modders might even like that because that means it's more difficult to reuse their assets, but you definetly want to supply the base game assets for mix ups, even if its a seperate download.

Also as i'm affected hardware wise having only a somewhat old gaming laptop and no desktop my "yea, do it! do it!" attitude is certainly not entirely neutral :D. Does steam offer hardware statistics per-game? Even if not there's certainly some good data on how many people you could benefit with this.

[bobingabout]

Also as i'm affected hardware wise having only a somewhat old gaming laptop and no desktop my "yea, do it! do it!" attitude is certainly not entirely neutral . Does steam offer hardware statistics per-game? Even if not there's certainly some good data on how many people you could benefit with this.

Well, They know that their new graphics system update (DX11 and OGL4 as minimum requirements) is going to break around 1% of their audience, so they can obviously see some sort of hardware and software lists.

[Jap2.0]

Also as i'm affected hardware wise having only a somewhat old gaming laptop and no desktop my "yea, do it! do it!" attitude is certainly not entirely neutral . Does steam offer hardware statistics per-game? Even if not there's certainly some good data on how many people you could benefit with this.

Well, They know that their new graphics system update (DX11 and OGL4 as minimum requirements) is going to break around 1% of their audience, so they can obviously see some sort of hardware and software lists.

Apparently Steam also gives specific hardware and software statistics for Factorio, per the FFF about 32 bit, so it's not just the public hardware and software survey, devs have specific subsets for their games.

[bobingabout]

Also as i'm affected hardware wise having only a somewhat old gaming laptop and no desktop my "yea, do it! do it!" attitude is certainly not entirely neutral . Does steam offer hardware statistics per-game? Even if not there's certainly some good data on how many people you could benefit with this.

Well, They know that their new graphics system update (DX11 and OGL4 as minimum requirements) is going to break around 1% of their audience, so they can obviously see some sort of hardware and software lists.

Apparently Steam also gives specific hardware and software statistics for Factorio, per the FFF about 32 bit, so it's not just the public hardware and software survey, devs have specific subsets for their games.

which again was about 1% of their audience.

[posila]

Yeah, we have Steam HW survey of Factorio players.

Tools are something we are lacking. I know artists use some python script to generate spritesheets from After Effects output, but that's about it. Part of the lack of tools problem is also that prototypes are pretty much hand written, and no matter what tool we make, somebody on the team will always keep modifying them by hand, so potential tool would need to iterpret lua and not screw up the files when saving modifications in it. Another part of the problem is support for multiple platforms - my go-to language for writing tools is C#. It's great for Windows guys, but would probably be hassle to make it work on all platforms in Mono.

So I think it is more likely to end up being extra step, rather than making things simpler. I was thinking maybe it could be done automatically when uploading to mod portal, but I am not sure if it would be possible with mods that have dependencies; and then I started to wonder if it wouldn't screw up compatibility between versions of mods (ie. some texture pack mod that is used by other mods)

We would want to use running from folder too, so that would be kept for sure. As for getting original PNGs, I am thinkin something like command line parameter that would dump all graphics to PNGs or TGAs.

As for benefits, well, it should benefit everyone. For starters, no sprite cropping as that would be already part of the preprocessed package; no need to define high-res and normal-res separately. Possibly faster startup to main menu, possibility to change mods without complete restart, ...

Thanks for the input so far.

[eradicator]

You say "the tool" would have to interpret lua, so maybe i'm thinking about this wrongly. I assumed that the prototype definitions would still be pretty much the same, just that instead of filename=/path/to/sprite-sheet.png we use filename=/path/to/sprite-blob.factorio. Unless you're talking about autogenerating part of the prototype definition (which sounds useful but isn't required)? As for the hassle of making the tool...well, think of the combined workload of all modders each reinventing the "how do i make a spritesheet" wheel, i'm sure it can't be as bad as all that combined p;.

As for "auto-convert on upload" wouldn't that mean mods uploaded directly to the forum (i.e. beta versions) would be...well, what would they be? And if it can be done completely automated why can't it be integrated into the current "atlas making" process, and thus be completely transparent to modders? Is it that much more computationally expensive? (would be throwing away faster startup times and/or lots of disk space but still be nice...).

As for possibile incompatibilities when mods use other mods textures, i'm not sure how this would cause additional incompatibilities. If anyone does that they'll already get buggy results with the current system if the version doesn't match.

As for benefits, well, it should benefit everyone. For starters, no sprite cropping as that would be already part of the preprocessed package; no need to define high-res and normal-res separately. Possibly faster startup to main menu, possibility to change mods without complete restart, ...

Those are all awesome points that i want yesterday :D.

[sthalik]

posila, post the required format's spec and semantics. Then the problem will solve itself before you finish the renderer. If you publish a sample implementation, all the better.

And if it can be done completely automated why can't it be integrated into the current "atlas making" process, and thus be completely transparent to modders?

posila, can you potentially do it on the mod repository? That gives somewhat more options.

[sillyfly]

I believe I posted about this a long time ago, but Factorio is definitely in the "uncanny valley" of having a high VRAM requirements with otherwise pretty low GPU needs. GPUs like an Nvidia 1050 or AMD 560 have way more "power" than Factorio actually needs, but only 2GB of VRAM.

I wonder if some clever use of Shaders could be employed to make low-quality sprites appear nicer, thus harnessing the untapped processing power of GPUs with plenty of compute but not a lot of VRAM...

[posila]

You say "the tool" would have to interpret lua, so maybe i'm thinking about this wrongly. I assumed that the prototype definitions would still be pretty much the same, ...

Ah, when I wrote about lack of tools I thought about some kind of prototype editor - you'd select prototype you want to edit, changed some values on it or drag and drop bunch of sprites to it and tell it which animation the sprites are supposed represent, it would create spritesheet and animation definition in prototype, you'd just check preview to see if shifting is correct and drag the image with your mouse to correct it ... that kind of thing. Not anything specific for "do something with high VRAM requirements for 0.17"

Is it that much more computationally expensive? (would be throwing away faster startup times and/or lots of disk space but still be nice...).

It depends ... For example if we decid to compress everything using BC7, it would be very time consuming. (But we won't decide to do that, because as I am writing this I realized it is texture format on DirectX11 class hardware). Anyway, I was under the impression the current cropping step is already almost unacceptable.

... filename=/path/to/sprite-sheet.png we use filename=/path/to/sprite-blob.factorio.

You would still write filename=/path/to/sprite-sheet.png, but the engine would now /path/to/sprite-sheet.png doesn't refer to a file but to a spritesheet inside of sprite-blob.factorio (that is simplified, it would be combination of name, x-offset, y-offset, width a height to uniquely identify a frame inside of sprite-blob.factorio)

posila, post the required format's spec and semantics. Then the problem will solve itself before you finish the renderer. If you publish a sample implementation, all the better.

I am still in phase of research and in this discussion I am trying to figure out how far I can go with changing how Factorio treats sprite assets.
Accessing lot of small files, is slower that reading single large file. Decompressing PNGs is slow, and you have to decompress whole file even if you want just small part of it (single frame in a sprite sheet). So the theoretical blob should contain all sprites, already cropped and separated to individual frames in format suitable for use on GPU without any conversion. The sprites should be present in multiple sizes, so if player has zoomed out view with lot of different sprites, we can load lot of different low detail sprites and when player zooms in, we load just a few high detail sprites that are visible.

[eradicator]

Anyway, I was under the impression the current cropping step is already almost unacceptable.

Well, faster startup times are of course desirable (especially for mod authors) but it all depends. For example if you could modify the current "atlas" caching paradigm to cache on a per-mod basis instead of an all-mods-at-once basis, then you could transparently do the pre-processing and cache the result, but only have a startup cost-penalty if a mod is updated (or if you go one step further and hash the input image only do processing if textures actually change), and only for that mod, this would also benefit people who frequenty change what mods they use (but not the mod versions) i.e. when they join a multiplayer game that has a different active mod/mod_settings set than their current one. Ofc that way mod authors still need to create spritesheets only to have them automatically dissassembled on startup (=wasted effort/time). So much for my idea of a possible "transparent" implementation, just for the sake of discussion, personally i'd still like a proper sprite-making-tool, especially now that you lured me in with possible "mouse drag to fix sprite shift", because ...that is a serious quit/restart torture right now.