low quality graphics ..

[kingarthur]

the sprites are already done in their sizes, to increase them i would need to re-render which i wont. Downsize them to make the actual as hi-res would mess with some pipe connections.

Hi-res assets require you to use scale = 0.5. Normal res assets use scale = 1. There is no apparent difference in perceived size in-game, the only different is the number of pixels that make up the sprite.

yes but the current graphics are all ready at scale 1. so without re rendering them all the normals would be blown up in size to match the current entity sizes

[kirazy]

the sprites are already done in their sizes, to increase them i would need to re-render which i wont. Downsize them to make the actual as hi-res would mess with some pipe connections.

Hi-res assets require you to use scale = 0.5. Normal res assets use scale = 1. There is no apparent difference in perceived size in-game, the only different is the number of pixels that make up the sprite.

yes but the current graphics are all ready at scale 1. so without re rendering them all the normals would be blown up in size to match the current entity sizes

Ah. So they're already low-res graphics, and it's the hi-res graphics that don't exist?

[eradicator]

low quality graphics

Also perhaps not exactly what was asked for, I just remembered the No Animations mod which claims to reduce VRAM usage significantly.

[kirazy]

Also perhaps not exactly what was asked for, I just remembered the No Animations mod which claims to reduce VRAM usage significantly.

I talked with kingarthur and he's going to implement frame_sequence as a means to maintain animations but with reduced frame count. Apparently py animations have an absurd number of frames.

[eradicator]

Also perhaps not exactly what was asked for, I just remembered the No Animations mod which claims to reduce VRAM usage significantly.

I talked with kingarthur and he's going to implement frame_sequence as a means to maintain animations but with reduced frame count. Apparently py animations have an absurd number of frames.

Sounds like a nice compromise if it works (what with frame_sequence being itself limited to 255 frames = 4.25 seconds at 60fps). Does that imply he's also going to add some kind of mod option to allow user control over how strong frame count is reduced? Hm...looking at the wiki page it sounds like it should even be possible to make "No Animations" style generic mod that uses frame_sequence to procedurally reduce animations.

[eradicator]

I hacked together a quick proof-of-concept dynamic sequence reducer. I don't have a map to test, so someone else will have to do that. If it works well enough I might release it to the portal.

Edit: Reduction ratio is a mod setting. Reduction of very short animations is a bit stuttery because of the simplistic poc algorithm, can probably be improved later.

Edit: Oops, forgot to add library dependency.

Edit2: There's now a proper polished mod portal release: Eradicator's VRAM Saver

PRIVATE USE ONLY. DO NOT REDISTRIBUTE.

eradicators-animation-reducer_0.1.1.zip

(3.25 KiB) Downloaded 534 times

[kingarthur]

Does that imply he's also going to add some kind of mod option to allow user control over how strong frame count is reduced?

you mean something like this? plan is that by default itll cut the number in half and if you max it out at 255 itll just cut the animations completely. itll only work on normal mode though as hr version will stay the same as now.

[eradicator]

you mean something like this? plan is that by default itll cut the number in half and if you max it out at 255 itll just cut the animations completely.

Heh, that's exactly how my setting works in the demo mod I posted above (lulz, 400+ downloads over night o_O). After some thought I think a simple 0-100% setting would be more intuitive to use though.

itll only work on normal mode though as hr version will stay the same as now.

I had the impression that the whole point is that there *is* only one version? Or are you making a copy for "normal" just to adjust the frames?

[eradicator]

So, after wasting way too much time on polishing the thing up and reducing the frame stutter I decided to officially publish it anyway so that other modpacks can benefit too.

I present you: Eradicator's VRAM Saver (let's see how long it takes this time to break 400 downloads...).

[kingarthur]

I had the impression that the whole point is that there *is* only one version? Or are you making a copy for "normal" just to adjust the frames?

there is currently only a normal version in the files. the code i was working on makes a copy and adds it as the high res version and then edits the normal res version to remove frames as i assume anyone using the hr version probably doesn't care about vram issues and cant break anything by messing with it.

[eradicator]

I had the impression that the whole point is that there *is* only one version? Or are you making a copy for "normal" just to adjust the frames?

there is currently only a normal version in the files. the code i was working on makes a copy and adds it as the high res version and then edits the normal res version to remove frames

I see. My procedural approach has two reduction settings, one for "normal" and one for "hr_version" (let the user decide what they need), and is completely agnostic to where the animations really come from. It just applies the sequence downsampling to anything it "finds". Mostly because it's much much simplier than writing a proper parser for recursive animation layers and having to care where those even are in each kind of prototype. Ofc your situation is different if you only need to deal with definitions that you wrote yourself :D.

as i assume anyone using the hr version probably doesn't care about vram issues and cant break anything by messing with it.

I don't know if I'm alone, but I do like the crispyness of HR tiles, belts, icons, character animations etc. So I'm using HR even though I only have 2gigs of VRAM. I think I might prefer reduced HR animations over full-animation-but-everything-lq. (Would need some actual playtesting.)

___
Also one thing I noticed is that many/most(?) py building animations don't scale with speed bonus (match_animation_speed_to_activity), is that on purpose? Because I experimented with really low frame-count animations (i.e. 3 frames) and I noticed that on assembling machines with very high speed bonus the frame reduction is quasi unnoticible because the animation runs so fast.

[Edit: On minimal frame count it does look better still, but it's only on medium frame count that is becomes unnoticible.]

[pyanodon]

the animations dont scale at purpose or on mk04 level with modules it would be too fast.

[BlueTemplar]

Grab gpu-z and check video memory usage in it. It will show you if you are actually filling up gpu's memory.

Yeah, also watch out for symptoms like these spikes in "GPU load" :

GPU_spikes.png (77.26 KiB) Viewed 5245 times

This helped making zooming much more smoother for me in 0.16 AB (despite only "10% GPU load"), might or might not apply here :

optimize_sprite_atlas.png (81.72 KiB) Viewed 5245 times

Also, what Zanthra said.

Considering your CPU : "6 AMD PHENOM II 1050", and therefore DDR3 RAM, it might not be the graphic card (especially a 8 Go one) that is the bottleneck. (32 Go of RAM might not help that much if the RAM is slow ?)

----

the sprites are already done in their sizes, to increase them i would need to re-render which i wont. Downsize them to make the actual as hi-res would mess with some pipe connections.

Hi-res assets require you to use scale = 0.5. Normal res assets use scale = 1. There is no apparent difference in perceived size in-game, the only different is the number of pixels that make up the sprite.

yes but the current graphics are all ready at scale 1. so without re rendering them all the normals would be blown up in size to match the current entity sizes

Ah. So they're already low-res graphics, and it's the hi-res graphics that don't exist?

Right, oh, wait, Factorio actually has THREE levels of graphics, with IIRC "low-res" being 1 pixel for 4 of normal too..?
... or was "low-res" actually deprecated with 0.17 ?

Also I remember mipmaps being added after 0.17.0, or was it just for icons & belt icons ?

----

Also perhaps not exactly what was asked for, I just remembered the No Animations mod which claims to reduce VRAM usage significantly.

I talked with kingarthur and he's going to implement frame_sequence as a means to maintain animations but with reduced frame count. Apparently py animations have an absurd number of frames.

Oh, is this going to help with the slowdown around biosamples "ore" ?

So, after wasting way too much time on polishing the thing up and reducing the frame stutter I decided to officially publish it anyway so that other modpacks can benefit too.

I present you: Eradicator's VRAM Saver (let's see how long it takes this time to break 400 downloads...).

Thank youuuu !

[kirazy]

Ah. So they're already low-res graphics, and it's the hi-res graphics that don't exist?

Right, oh, wait, Factorio actually has THREE levels of graphics, with IIRC "low-res" being 1 pixel for 4 of normal too..?
... or was "low-res" actually deprecated with 0.17 ?

Also I remember mipmaps being added after 0.17.0, or was it just for icons & belt icons ?

Mipmaps are for icons, and per https://wiki.factorio.com/Prototype/Animation, doesn't look like low_res is a thing.

You could easily fake it, though, by making a smaller image and then setting scale = 2 and have that be "normal", and your hi-res be your standard normal...

[eradicator]

Thank youuuu ! :D

Np. Feel free to run around the internet and advertise ;).

Also I remember mipmaps being added after 0.17.0, or was it just for icons & belt icons ?

Mipmaps are for icons, and per https://wiki.factorio.com/Prototype/Animation, doesn't look like low_res is a thing.

Mipmaps are supported on lots of stuff, including Animation which you just linked. But mipmaps are a memory-for-speed trade. They consume *more* memory, not less.

[kirazy]

Mipmaps are supported on lots of stuff, including Animation which you just linked. But mipmaps are a memory-for-speed trade. They consume *more* memory, not less.

Code: Select all

mipmap_count
Type: uint8
Default: 0
Only loaded if this is an icon (has flag "group=icon" or "group=gui").

[Zanthra]

Mipmaps are supported on lots of stuff, including Animation which you just linked. But mipmaps are a memory-for-speed trade. They consume *more* memory, not less.

Code: Select all

mipmap_count
Type: uint8
Default: 0
Only loaded if this is an icon (has flag "group=icon" or "group=gui").

I think that option is to prevent mipmaps generation for icons and GUI elements that are drawn at specific scale ratios. Basically mipmaps are always generated in full for non-icons, and if the mipmap_count is specified, a specific number can be generated for icons if they are expected to be drawn at half scale or quarter scale etc.

Basically the default for icons is 0, thus 0 levels of mipmap.

[eradicator]

Mipmaps are supported on lots of stuff, including Animation which you just linked. But mipmaps are a memory-for-speed trade. They consume *more* memory, not less.

Code: Select all

mipmap_count
Type: uint8
Default: 0
Only loaded if this is an icon (has flag "group=icon" or "group=gui").

Yea, but is there a mechanism that prevents setting that flag on an entity (etc.) animations? After scrolling through the whole prototype overview I haven't seen a single instance where a Prototype/Animation is used as an icon. Only Prototype/Sprite and IconSpecification seem to be used as icons, and the latter has icon_mipmaps not mipmap_count. So I'm a bit puzzled what the intention is there.

Anyway, the main thing I wanted to say: mipmaps are not meant to reduce VRAM usage.

[kirazy]

Yea, but is there a mechanism that prevents setting that flag on an entity (etc.) animations? After scrolling through the whole prototype overview I haven't seen a single instance where a Prototype/Animation is used as an icon. Only Prototype/Sprite and IconSpecification seem to be used as icons, and the latter has icon_mipmaps not mipmap_count. So I'm a bit puzzled what the intention is there.

Anyway, the main thing I wanted to say: mipmaps are not meant to reduce VRAM usage.

Oh, I agree mipmaps don't save memory. I was just contesting the idea they can be used for more than just icons. I don't quite buy Zanthra's response, unless we're talking about different things. When discussing mipmaps I don't really mean the auto-generated mipmaps the game creates, I mean the manually created mipmaps that are added in the files at specific scaling steps. I don't think there's a way to do that for anything but icons.

[eradicator]

Oh, I agree mipmaps don't save memory. I was just contesting the idea they can be used for more than just icons.

And I'm not contesting that mipmaps are *intended* to be used for icons. Just saying that the docs suggests that it's a simple flag check and thus I'd assume they can be used on non-intended things too.

I don't quite buy Zanthra's response

Neither do I. Unless icon_mipmaps and sprite/animation mipmap_count are completely different implementations.