[FEATURE] VRAM requirement is not sane

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

orzelek
Smart Inserter
Smart Inserter
Posts: 3924
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by orzelek »

I've just read about BC6/7 formats and it's a bit sad that there is no way to use them due to required dx level.

Any chance that if you actually implement some kind of texture blobbing that would create temporary texture blob for game to use you could include an option to make it in BC7?
sthalik
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Tue May 01, 2018 9:32 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by sthalik »

posila wrote: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.
Why not create a cache file for each mod like this? Right now even with supported options, loading assets into VRAM takes its time. Creating a cache would be slightly slower than as of now, and later pretty fast given direct upload with same surface format.
posila wrote: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.
You intend to swap them from disk then? I have to say this is sensible. "mmap" would work nice here. Also using separate buffer objects (I assume) for the mipmaps will reduce thrashing. It happens more when zoomed out. Please consider storing animations separately too.

Interesting, you can set stride length to full image width (minus X offset) for each individual image and have it Just Work.
bobucles wrote:Turning the world into a censored pixel blob is probably the worst solution.
I did some initial quality tests for S3TC using the SSIM metric. The metric gives bad results, sprites with visibly washed out colors are marked as high quality. I'm gonna try using the PSNR metric next time since that measures information content per pixel (kind-of-like entropy; more simplified after compression, less information density). The thing is that at 50% size of the compressed image I don't see any difference anymore. This may be 4K but I stuck the nose to the screen a bit.

The differences (or lack of thereof) are best visible with a .gif alternating between .png and .dds content.

posila, when is the drawn sprite exactly its full image size? Is it the highest (non-debug) zoom or does game resolution come into play also?
posila
Factorio Staff
Factorio Staff
Posts: 5359
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by posila »

sthalik wrote:Why not create a cache file for each mod like this? Right now even with supported options, loading assets into VRAM takes its time. Creating a cache would be slightly slower than as of now, and later pretty fast given direct upload with same surface format.
Hmm, I suppose doing it for mods on user side would not be end of the world. Optionally, mod authors could pre-preprocess their mods if they wanted to speed things up for players.
sthalik wrote:posila, when is the drawn sprite exactly its full image size? Is it the highest (non-debug) zoom or does game resolution come into play also?
When you press F9 the game changes view to zoom 1, which is native normal-res. When you zoom in 8 clicks of mouse wheel, it's zoom 2, which is native high-res, but you can zoom in little bit further (to zoom 3.6). Resolution only affects how much you can zoom out (because we have constant maximum number of tiles can you see across width of the screen). You can see zoom value under show-detailed-info in debug menu (F4)
User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2529
Joined: Fri Nov 06, 2015 7:41 pm

Re: [FEATURE] VRAM requirement is not sane

Post by Deadlock989 »

posila wrote:
sthalik wrote:Why not create a cache file for each mod like this? Right now even with supported options, loading assets into VRAM takes its time. Creating a cache would be slightly slower than as of now, and later pretty fast given direct upload with same surface format.
Hmm, I suppose doing it for mods on user side would not be end of the world. Optionally, mod authors could pre-preprocess their mods if they wanted to speed things up for players.
This would also have the advantage of making it much easier to tinker with mods in development. I often find that a sprite I've prepared doesn't look as good in-game as it does in isolation, so I go back and tweak it several times. If the game could still work with uncompressed pngs in mods, but allow us to pre-process them for "finalised" graphics, that would be ideal.
sthalik
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Tue May 01, 2018 9:32 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by sthalik »

What issues do you have with creating new assets and packing the mod? There should definitely be a tool making it all in one go. And I can help!

I can think of making sprite sheets for animations. These can be made with some Python or shell imagemagick invocations, keeping source material intact.

Are there any other examples of something artists and others don't like? If you made a list of mod pipeline problems then it's all doable with a program/script. Can you make a thread detailing mod pipeline problems?
User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2529
Joined: Fri Nov 06, 2015 7:41 pm

Re: [FEATURE] VRAM requirement is not sane

Post by Deadlock989 »

sthalik wrote:What issues do you have with creating new assets and packing the mod? There should definitely be a tool making it all in one go. And I can help!

I can think of making sprite sheets for animations. These can be made with some Python or shell imagemagick invocations, keeping source material intact.

Are there any other examples of something artists and others don't like? If you made a list of mod pipeline problems then it's all doable with a program/script. Can you make a thread detailing mod pipeline problems?
Currently, no issues. I have Blender set up the way I like it. Turning the output from that into sprite sheets is just a couple of clicks with the free features of TexturePacker.

I'd really rather not get command-line / shell script stuff involved. ImageMagick makes me break out in hives. I don't mind an "extra step" for this pre-processed idea but ideally I'd like to not have to do it every single time I tweak a sprite, but just once when a mod version is finalised for uploading to the mod portal, and the uncompressed pngs can still run from a mod folder during development.
sthalik
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Tue May 01, 2018 9:32 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by sthalik »

Sorry, that's a misunderstanding. What I meant is to provide a one-click converter that does the right thing. Question is whether it's needed to begin with, for any modding tasks.
User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 7352
Joined: Fri May 09, 2014 1:01 pm
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by bobingabout »

what I'd like to see:

I have a mod (as is now) I run a mod packing program, and press go. Mod is processed and zipped into the new format.

Basically, all that changes is the zipping it step.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5207
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by eradicator »

If you're redoing how textures are loaded it'd also be very nice if you considered an old request of mine:
Support for Variable Animation Framerate
because i often feel like i'm wasting most of the VRAM for identical frames.
sthalik
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Tue May 01, 2018 9:32 am
Contact:

Re: [FEATURE] VRAM requirement is not sane

Post by sthalik »

bobingabout wrote:what I'd like to see:

I have a mod (as is now) I run a mod packing program, and press go. Mod is processed and zipped into the new format.

Basically, all that changes is the zipping it step.
I can write you a Python program you can invoke right after! Is that enough?
Post Reply

Return to “Ideas and Suggestions”