You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Albedo and Normal Textures for terrain Materials only allow Image and Compressed Image textures.
This makes sense for Quick Art Prototyping from Within Godot, whilst also keeping file sizes to a minimum for prototypes (a few kb per texture vs dozens of mb per texture) albeit at the expense of longer loading times and higher VRAM consumption (as it has to generate the textures and they aren't compressed)
The text was updated successfully, but these errors were encountered:
It's a cool idea. I played with it today, but it's not practical at the moment.
I can make a separate noise texture resource and bring it in. However, upon restarting the texture is invalid. In the editor you must double click the texture resource to start generating, then reassign the textures to the slots again. The textures are generated in a thread, and in gdscript you must request the load, then await until it is done. We don't have that option in C++. It would take quite a bit of restructuring to allow textures to lazy load noise textures at startup.
I don't have an option to detect when the noise texture changed. It doesn't emit texture_changed when you change noise settings. So to get updates, you have to change the noise texture, then assign it to the texture slot again.
So I'll say this won't be implemented unless NoiseTexture no longer lazyloads, which will be never; or we redesign our system to facilitate dynamic textures. Perhaps when we build terrain generation with GPU based noise algorithms, we could build in noise generated textures.
Description
Currently Albedo and Normal Textures for terrain Materials only allow Image and Compressed Image textures.
This makes sense for Quick Art Prototyping from Within Godot, whilst also keeping file sizes to a minimum for prototypes (a few kb per texture vs dozens of mb per texture) albeit at the expense of longer loading times and higher VRAM consumption (as it has to generate the textures and they aren't compressed)
The text was updated successfully, but these errors were encountered: