TextureLayered subclasses don't serialize properly when created from a tool script

[Shfty]

Godot version:
3.1.2 / 3.2 beta 3

OS/device including version:
Windows 10 Pro 10.0.18362 Build 18362

Issue description:
TextureLayered resources (as well as their Texture3D and TextureArray subclasses) can be created without issue via the import process by selecting the appropriate Import As option, but creating them from a tool script results in instances that can't be serialized.

I've been trying to use a TextureArray to implement a mipmap-friendly texture atlas for the Qodot project, which works well, but can't be saved into a scene due to this issue.

Steps to reproduce:

• Open the project below
• Open texture_array_test.tscn
• Select the root scene node
• Click the 'reload' checkbox in the inspector
• A message detailing the contents of the created TextureArray will print to the log
• Save the scene
• The following error will appear in the log once per texture layer:
  • ERROR: Resource was not pre cached for the resource section, bug? At: scene/resources/resource_format_text.cpp:1372
• Reload the scene
• The following error will appear in the log, once per texture layer:
  -ERROR: _set_data: Condition ' !img.is_valid() ' is true. Continuing..: At: **scene/resources/texture.cpp:2093**
• The TextureArray exported from the root node will now have empty layers

Minimal reproduction project:
TextureArrayBug.zip

[Shfty]

I wrote a simple wrapper class to work around the problem for the use-case of TextureLayered-powered ShaderMaterials on MeshInstance nodes:
https://github.com/ShiftyAxel/TextureLayeredMesh

It's no fix, but it might help anyone having the same issue in the meantime.

[vwood]

I couldn't get importing of TextureArrays to do anything useful at all in 3.2.2

[arccoza]

@vwood a bug was introduced in the LayeredTexture importer in 3.2.2, fixed in 3.2.3

[arccoza]

Working on Cartographer I ran into a lot of bugginess in TextureArray in Godot 3.2. You can't save a TextureArray in the scene, or in a .tres or .res file properly (it saves the image data, but the index array is filled with nulls), as well as a collection of other odd behaviour.

It looks like they're getting some attention in 4, but for now the importer is the only stable way to create TextureArrays natively, but its usefulness is limited.

So, long story short; I ended up creating a custom ResourceSaver for TextureArrays that saves them in the same format that the importer does, as a .texarr file. You don't need a custom ResourceLoader because the builtin loader understands .texarr files.

I also created a custom EditorImportPlugin for TextureArrays that builds them from simple JSON files. Just describe the TextureArray as a JSON structure of other images or textures, and the importer bungs them all in the TextureArray.

If they're useful to you, or others, I can extract them as a standalone plugin.

[Calinou]

@arccoza Have you seen the TextureLayeredMesh add-on? If so, what did it miss?

[arccoza]

Hey @Calinou, sorry for the very slow response, I've had no time for Godot recently.
I've had a look at TextureLayeredMesh, and while it works at saving and loading, it's usecase specific, being bound to a custom node. Like my first attempts at solving this, it's a long workaround.

While fishing through Godots importer code for hints, I realized you only need a custom ResourceSaver that can save TextureArrays as the Godot .texarr file format. The builtin ResourceLoader will automatically load .texarr files with no problem.

Unfortunately the importer doesn't expose its save methods to GDScript, so I essentially re-implemented the importer save method in GDScript, as a ResourceSaver for TextureArrays. The benefits of this are you don't need any custom wrapper Nodes or Resources, and can save to .texarr from the editor save resource dropdown menu.

[woodbyte]

So, I've ran into this issue recently while trying to use precomputed/procedurally generated 3D textures to accelerate a raymarching shader which renders all sorts of nebulae in a space sim game.

I'd like to thank @Shfty for his workaround TextureLayeredMesh which seems to be a viable way forward for my project, and ask if anyone here knows if a fix is intended for some future 3.2.x release or if it will instead only be addressed in Godot 4 as hinted by @arccoza above.

Thank you.

[Calinou]

I'd like to thank @Shfty for his workaround TextureLayeredMesh which seems to be a viable way forward for my project, and ask if anyone here knows if a fix is intended for some future 3.2.x release or if it will instead only be addressed in Godot 4 as hinted by @arccoza above.

As far as I know, nobody has looked at fixing this in the 3.2 branch yet. That said, since there are few knowledgeable contributors about texture arrays and importers, I doubt it will be fixed before 4.0 is released.

[arccoza]

I've extracted the tools and UI from Cartographer for working around this as a stand-alone plugin; BetterTextureArray, get it here: https://github.com/awkwardpolygons/better-texture-array
I hope you find it useful.