Singletons such as RenderingServer should be accessible in MODULE_INITIALIZATION_LEVEL_SCENE

[Zylann]

Godot version

4.1

godot-cpp version

4.1

System information

Windows 10 64 bits NVIDIA GeForce GTX 1060

Issue description

RenderingServer::get_singleton returns null in cases where it should not.

• If you have code in your extension library initializer that tries to access RenderingServer, it will crash because that singleton will be null, even in initialization levels that should definitely work in modules (like MODULE_INITIALIZATION_LEVEL_SCENE).

• Similarly, if you have code in a class constructor (node, resource...) that tries to access RenderingServer, it will also crash the editor on startup, because EditorHelp creates temporary instances of every class in ClassDB to access the default values of their properties (mentionned in There should be a way to register classes without exposing them (usually editor plugin internals) #1179).

• In fact, if you dare calling RenderingServer::get_singleton() and it returns null, it will keep returning null forever, because in GodotCpp the wrapper caches the value once in a static variable and never runs again:

  godot-cpp/binding_generator.py

  Line 1458 in 749b0b9

  "\tstatic GDExtensionObjectPtr singleton_obj = internal::gdextension_interface_global_get_singleton(_gde_class_name._native_ptr());"

This is also the case with other servers such as PhysicsServer.

In all the mentionned cases, the server singleton actually exists.
Apparently the cause during initialization is that singletons in GDExtension are accessed similarly to scripts, which is terrible because that API is initialized way too late and completely disregards MODULE_INITIALIZATION_ levels.
This is very confusing and impractical. GDExtension needs the same access API modules have.

I notably work on a big module project, which can also compile as a GDExtension, so finding workarounds gets more complicated.

Steps to reproduce

Access RenderingServer::get_singleton() inside your library initializer, in MODULE_INITIALIZATION_LEVEL_SCENE, or access it inside the constructor of a custom class.

Minimal reproduction project

N.A

Alternative (theory)

This came up in a meeting: in modules, Godot is currently mixing up registration (declaring that X is there, but not executing anything) and initialization in modules. And by extension... extensions too 😁 In an ideal world, these two steps should be very separate.

In my module, I don't actually need to initialize singletons in MODULE_INITIALIZATION_LEVEL_SCENE, I just do it there because in the present state of things, I can do it there. But in GDExtension there is nowhere I can do it which won't cause the present issue.

Though regardless of this idea, there would still be a need to be able to order each step, because registration can depend on other things (base classes?), and initialization can also depend on others (accessing a core singleton when initializing a custom singleton).

[Splizard]

Also tracked here: godotengine/godot#64975