Are 8K Materials supported?

dustin

I realize that 8k is way overkill for even a PBR material, but, I was just experimenting with textures. Just for fun, I was using the 8k version of some free textures. Importing them took a REALLY long time. It was over 10 minutes just to import them(5 files) into the project. Then, adding each one to their appropriate slot in the Spatial Material took several more minutes each(and pegs all 8 cores of my cpu). This is compared to only taking a few seconds to do both for a 2k material.

So, is this a bug? A feature that might be addressed in the future? Any insight as to why it would take so long? I'm wondering if there might be some optimization for importing smaller sized images, but greatly increases on the larger sizes. I'm not above editing config files or even experiment with changing engine code. I'm an experienced programmer, but a newbie at games & 3D so I'd need a little guidance to point me in the correct direction.

TwistedTwigleg

I think, and I could be wrong, that I remember reading that 4k is the largest supported file size in Godot for most platforms. Looking through the GitHub repository, here are a few issues I found referencing large texture sizes:

Theoretically resizing the textures to 4K should fix the problem, while giving a nice visual. For most projects, using textures over 4K would probably be too taxing to render in real time (30-60+ FPS) anyway.

As for it being a bug, I have no idea. My graphics programming knowledge is rather limited. Most of what I know is from Google searches and some OpenGL experiments :sweat:

From what I can gather, it appears the maximum texture size various depending on the platform OpenGL is running on.

Wild Fire Games released a OpenGL maximum file size report that might help serve as a reference. However, I believe that is only for desktop platforms, I think mobile is a little more restricted. Looking at the chart, it looks like 8K textures are supported on the majority of desktop platforms though, so maybe it is just a setting somewhere in Godot?

Here is a Unity answer showing texture sizes for some mobile platforms.

With Godot 4 having a new Vulken rendering backend, it is possible the texture size limits will be less and larger textures can be imported. I have no idea what Reduz, or any of the other Godot developers, have planned though.

I think there is a engine development channel on the Discord/IRC for Godot, where others there might know better on the limitations and what is going on. It does seem rather strange that it takes so long to import and use 8K files in Godot.

I wish I knew more, but honestly I have no idea. Hopefully someone who knows more will chime in.

Megalomaniak

1024x1024 pixels = 1048576 pixels. (edit)8192x8192 pixels = 67108864 pixels(64 times more /edit).

1 RGBA pixel is 4 bytes. So one 8K RGBA texture is just shy of 2GB of memory.

When you are loading an image as a texture, first it needs to be decompressed, then re-compressed and loaded into memory. I do expect 8K textures to be pretty heavy, yeah.

dustin

Megalomaniak, you know when you lay out the math like that, that makes perfect sense. Twisted, thanks for the links. They were educational

Personally, I think even 2k textures are overkill, but the masses are always demanding more fidelity. I'll stick with 1 and 2k textures for now.

I think Godot now can support 8k, the problem is just the load time(when they do load, they work). I think the "problem" can be solved by allowing the decompression to happen in a background process so that the whole editor doesn't freeze while it is trying to decompress a png or jpeg. So if anyone wanted to regularly load 8k textures, they'll want to first change the editor a bit.

lawnjelly

Even authoring 8K textures is not easy (for e.g. movies), let alone trying to render them in realtime! :smile:

Approaches that are commonly used assuming linear layout in memory really don't work once textures get that big. Consider the cache consequences of drawing a small triangle from one side of a UV map that is 8096x8096. So you end up having to use different approaches such as tiling. Not just for rendering, but for everything in the pipeline, loading, converting etc etc.

Megalomaniak

Hence why UDIM's are a interesting concept. Also sparse virtual textures.

keltwookie

@Megalomaniak said: Hence why UDIM's are a interesting concept. Also sparse virtual textures.

Wow, It is the first time I read about these. After a littler googlizing, yeah, very interresting. @Megalomaniak Have these features been added to Godot Engine? Or is it planned? Or?

Megalomaniak

Nope, but sparse textures might get featured in the vulkan renderer perhaps. GLES only supports them from 3.1 on-wards and we never got anything beyond 3.0 previously.

keltwookie

@Megalomaniak said: Nope, but sparse textures might get featured in the vulkan renderer perhaps. GLES only supports them from 3.1 on-wards and we never got anything beyond 3.0 previously.

So, it has already been planned for further versions if I well understood. Many thanks for the answer, :)

Megalomaniak

No I meant that Vulkan renderer would be able to support it, while the previous ones weren't even an option.

keltwookie

Oh okay, sorry for misunderstanding.
Anyway, it still remains interesting features to implement.

oliiix

argh.. need udim supporrrttttt

Megalomaniak

Well, it certainly would be nice to have, but without sparse virtual textures I'm not sure it's of too much use, some, but probably less than ideal.

cybereality

In my tests, even 2K was too much for mobile. I had one cube in a scene and I couldn't get 60 fps.

Calinou

Note that Godot 4.0 will support optional Basis compression, which makes textures significantly smaller on disk. However, this will slow down the project exporting and make them slower to load.

@cybereality Indeed, I wouldn't use more than 1K on mobile myself. Mobile displays are smaller, so you can afford using lower-resolution textures with a less noticeable quality loss. Also, file size is critical on that platform, so you wouldn't want to use textures that are too large anyway.