Custom texture resource with server/headless build does not load

[kruffin]

Godot version

3.4.2-stable

System information

Ubuntu 20.04, AMD Radeon RX 6700 XT (21.40.1), Dummy

Issue description

A project with a custom resource that loads into an stex fails to load the resource with the server and headless binaries, blocking the program from running. Should custom resource loaders be used by the server binaries and if not, it should at least not block the program from running.

Error message seen:

$ ./Godot_v3.4.2-stable_linux_server.64 --main-pack packed_tex_test.pck -v
Godot Engine v3.4.2.stable.official.45eaa2daf - https://godotengine.org
 
CORE API HASH: 0
EDITOR API HASH: 0
Loading resource: res://default_env.tres
Loading resource: res://PackedTexTest.tscn
Loading resource: res://texture_data/HterrainServer_slot0_albedo_bump.packed_tex
ERROR: Failed loading resource: res://texture_data/HterrainServer_slot0_albedo_bump.packed_tex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
ERROR: res://PackedTexTest.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://texture_data/HterrainServer_slot0_albedo_bump.packed_tex
   at: poll (scene/resources/resource_format_text.cpp:412)
ERROR: Failed to load resource 'res://PackedTexTest.tscn'.
   at: load (core/io/resource_loader.cpp:206)
ERROR: Failed loading resource: res://PackedTexTest.tscn. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
ERROR: Failed loading scene: res://PackedTexTest.tscn
   at: start (main/main.cpp:2011)
WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
     at: cleanup (core/object.cpp:2064)
Leaked instance: ViewportTexture:1291 - Resource path: 
Leaked instance: BulletPhysicsDirectSpaceState:1293
Leaked instance: Image:1300 - Resource path: 
Leaked instance: Environment:1297 - Resource path: res://default_env.tres
Leaked instance: Physics2DDirectSpaceStateSW:1290
Leaked instance: Image:1301 - Resource path: 
Leaked instance: MultiplayerAPI:1294
Leaked instance: SceneTree:1287
Leaked instance: Viewport:1288 - Node name: root
Leaked instance: World2D:1289 - Resource path: 
Leaked instance: World:1292 - Resource path: 
Leaked instance: ProceduralSky:1296 - Resource path: res://default_env.tres::1
Hint: Leaked instances typically happen when nodes are removed from the scene tree (with `remove_child()`) but not freed (with `free()` or `queue_free()`).
ERROR: Resources still in use at exit (run with --verbose for details).
   at: clear (core/resource.cpp:417)
Resource still in use: res://default_env.tres (Environment)
Resource still in use: res://default_env.tres::1 (ProceduralSky)
Orphan StringName: tree_changed
Orphan StringName: _server_disconnected
Orphan StringName: network_peer_connected
Orphan StringName: _vp_unhandled_input1288
Orphan StringName: World2D
Orphan StringName: BulletPhysicsDirectSpaceState
Orphan StringName: _network_peer_connected
Orphan StringName: ProceduralSky
Orphan StringName: _network_peer_disconnected
Orphan StringName: node_added
Orphan StringName: World
Orphan StringName: Viewport
Orphan StringName: network_peer_disconnected
Orphan StringName: node_removed
Orphan StringName: Physics2DDirectSpaceStateSW
Orphan StringName: root
Orphan StringName: MultiplayerAPI
Orphan StringName: Environment
Orphan StringName: _vp_gui_input1288
Orphan StringName: _connection_failed
Orphan StringName: SceneTree
Orphan StringName: _vp_input1288
Orphan StringName: connected_to_server
Orphan StringName: node_renamed
Orphan StringName: connection_failed
Orphan StringName: Image
Orphan StringName: _vp_unhandled_key_input1288
Orphan StringName: _connected_to_server
Orphan StringName: ViewportTexture
Orphan StringName: server_disconnected
StringName: 30 unclaimed string names at exit.
ERROR: There are still MemoryPool allocs in use at exit!
   at: cleanup (core/pool_vector.cpp:63)

Steps to reproduce

In this particular case, it requires a custom resource that imports as a stream texture being applied as the material on a model. The project will run correctly until a server or headless binary is used to run the pck. It seems this has something to do with the Dummy video driver but am not sure how to track that down.

Minimal reproduction project

https://github.com/kruffin/packed_tex_test
packed_tex_test-master.zip

[Calinou]

This likely occurs because Godot does not actually load texture data in headless/server builds. Methods that return texture size will typically return a size of (0, 0) and pixel data will always be considered fully black. Texture data is generally not needed in server exports, so this is done to save memory usage when running a dedicated server.

Having a way to read texture data in a server export would need to be implemented in a selective manner (on a per-texture basis), as described in godotengine/godot-proposals#2756. Godot 4.0 no longer uses a server platform and uses a --headless command line argument instead, but I presume the same issue applies there too.

[kruffin]

Thanks for taking a look at this. Is there a way to mark this custom resource so that it doesn't try to load in headless/server builds?

[kruffin]

Thanks again Calinou. I put together a small workaround for this here (https://github.com/kruffin/packed_tex_test/tree/workaround) The gist is I had to save the custom resource as a tres and optionally load it if not running on a server binary:

onready var mesh = $MeshInstance

func _ready():
	if !OS.has_feature("Server"):
		var mat = load("res://PackedTexTest.tres")
		mesh.mesh.surface_set_material(0, mat)

It's not pretty and would be nice if there is a way to tell the server binary not to try and load a particular resource, but should work in a pinch.