In continuation of the question https://godotengine.org/qa/35751/how-do-i-use-different-texture-resolutions, I want to offer a new opportunity.
Loading textures or materials in scripts is a bad way. I think I have a good idea how to automate this.
This will automate the support of textures of different resolutions in the game.It is enough to load textures of different resolution levels into the project + add to the game settings, switching one global variable. Textures strongly affect memory and performance. I think this is a very useful function.
For the record, there used to be a "shrink by 2脳" option in the Export settings which was useful to decrease file size when exporting a PC game to mobile/Web platforms, but it wasn't reimplemented in the 3.0 export system.
Another approach I could imagine is giving each texture (or mesh) a number representing it's texture detail level. This can be compared against a global reference value (= the quality setting) deciding which resolution to load.
For example if a cube has a texture "detail value" of 2 and the quality setting is set to 1 you would load the texture that is 1/2 of the original one. If you set the quality to 0.5 you would go for 1/4, etc.
This could also be used for advanced things like texture streaming: The visible detail of an object is proportional to 1/distance - which can be used to determine which texture level should be loaded.
@CptPotato Sounds good to me, but there should also be a way to make the global quality factor ignore some textures such as GUI elements.
No, I'm not talking about changing the texture when exporting! I'm talking about switching the textures in the exported game!
I want to display in the settings the ability for the user to choose the quality of textures based on the characteristics of his PC.
Another approach I could imagine is giving each texture (or mesh) a number representing
Mesh and so have LOD.
The visible detail of an object is proportional to 1/distance - which can be used to determine which texture level should be loaded.
This makes MIP-MAP filtering. Right?
No, I'm not talking about changing the texture when exporting! I'm talking about switching the textures in the exported game!
Yes, that's what I meant, sorry if I was a bit unclear.
Mesh and so have LOD.
That's not quite what I was referring to. I thought about a texture detail that you can either define on a per-texture or per-mesh basis.
This makes MIP-MAP filtering. Right?
Kind of, mip maps are lower resolution versions of a texture so they're also handy for this task (no need to create extra textures). Though, what I meant is: if an object is far away (or very small on the screen) you can get away with lower resolution textures - so if texture streaming is implemented you could only load the smaller mip levels, saving texture memory. If you get closer you can stream the higher resolution versions.
Kind of, mip maps are lower resolution versions of a texture so they're also handy for this task (no need to create extra textures). Though, what I meant is: if an object is far away (or very small on the screen) you can get away with lower resolution textures - so if texture streaming is implemented you could only load the smaller mip levels, saving texture memory. If you get closer you can stream the higher resolution versions.
This will allow you to control the maximum size of the loaded texture? Will allow to avoid loading in memory of the big initial texture (will allow not to occupy memory)?
I'm not really that tech savvy aspects. Perhaps this is why I do not quite understand the essence of your proposal. I just want the finished game to be able to be adapted to relatively weak PCs without re-exporting. What would the user can go to the game settings and switch textures 512/1024/2048, etc.and thus significantly reduced the requirement of the game on video memory and render.
This will allow you to control the maximum size of the loaded texture? Will allow to avoid loading in memory of the big initial texture (will allow not to occupy memory)?
What I said about the texture streaming method is more of a "would be nice to have"-thing, rather than a suggestion for the next steps towars implementing texture quality settings.
A very basic implementation for the first shot could be a simple scale factor (or mip level factor) without any of the special weighting I've described above. You can decrease the size of all textures by 2x, 4x, 8x etc.
And of course the large textures should not be moved to the video memory when only the smaller ones are being used.
But as Calinou said, it's important that you can manually exclude/include specific textures from this process to prevent things like UI elements from getting low res and blurry.
One problem with UI and sprites though is that the size of some elements is determined by texture size, so you can't only swap by a lower-res texture, you have to somehow remember which size it should have and stretch it. But that would not be a problem for 3D.
Perhaps I do not understand the essence of the proposed implementation...
But I wrote only about the simple forced control textures for 3D objects. It would be great to have a simple, transparent way to choose the texture size.
It would be nice if you could set up quality levels similar to unity. As mentioned above some textures shouldn't be scaled and others you might want to scale more/less depending on the asset.
I noticed that shrinking all textures when the project loads is already possible, as explained in the Multiple resolutions documentation. However, this will apply to everything including 2D/GUI elements, which may be undesirable.
Can I use the texture_set_size_override method on the virtual server to achieve this effect?
can't see it in the latest doc, If it works for me, then I just won't update the engine.
Most helpful comment
For the record, there used to be a "shrink by 2脳" option in the Export settings which was useful to decrease file size when exporting a PC game to mobile/Web platforms, but it wasn't reimplemented in the 3.0 export system.