An explanation on the custom modules.

[themistocles-0]

Your Godot version: 3.4.2

Issue description: Documentation regarding building godot from source should be enhanced, specifically which modules can be safely omitted within the custom.py, and which circumstances it is safe to omit them. I found very little information on the documentation website about what each module specifically does, and the automatic custom.py generator site does not explain every module listed with scons --help. I intend to use custom modules heavily, and want to optimize my build times as much as possible.

URL to the documentation page (if already existing): https://docs.godotengine.org/en/stable/development/compiling/optimizing_for_size.html

[Calinou]

and the automatic custom.py generator site does not explain every module listed with scons --help.

Could you write a list of missing options here? Note that I don't list editor-only modules by design, as there is no point in disabling them to reduce the size of an export template binary.

[themistocles-0]

I'm interested in finding a way to reduce the build times overall, while at the same time have only what I need compiled.

[themistocles-0]

I need to know what all the editor modules do, and if I must not disable their compilation, +recast, whether the engine works if I choose to disable fbx(I intend to work solely in gltf)

[Calinou]

whether the engine works if I choose to disable fbx(I intend to work solely in gltf)

The editor will still work if you disable specific import modules.

[themistocles-0]

The editor will still work if you disable specific import modules.

Recast? Vhacd? Squish? Pvr? Lightmapper_rd?

[Calinou]

Recast? Vhacd? Squish? Pvr? Lightmapper_rd?

Yes to all :slightly_smiling_face:

Recast is needed if you use NavigationServer though, and VHACD is needed if you use 3D convex shape decomposition.

Squish is used for VRAM texture compression, and is only needed in 3D projects that use high-resolution textures.

PVR is for PVRTC, and has been removed in 4.0 and it's almost never used nowadays (it was only useful when targeting iOS).

lightmapper_rd is used in the GPU lightmapper, so you only need it if you intend to use the BakedLightmap node.

[themistocles-0]

What about the ones listed below? Is it catastrophic to disable them in the build?

1. assimp
2. basis_universal
3. cvtt
4. denoise
5. xatlas_unwrap
6. webxr Is there a place every single module is detailed?

[themistocles-0]

What about the ones listed below? Is it catastrophic to disable them in the build?

1. assimp
2. basis_universal
3. cvtt
4. denoise
5. xatlas_unwrap
6. webxr Is there a place every single module is detailed?

What about lightmapper_cpu?

[Calinou]

What about lightmapper_cpu?

The CPU lightmapper module is used to bake lightmaps in Godot 3.x, but you can disable it if you don't intend to bake BakedLightmaps with your editor binary. xatlas_unwrap and denoise are also only used in the lightmapping process.

cvtt and basis_universal are used for VRAM texture comprssion, so they're only needed when working on 3D games with high-resolution textures.

assimp is used for FBX import, which means you only need it if you're importing FBX scenes in a 3D project.

webxr is used for VR support in HTML5, and is only enabled in HTML5 builds.

[themistocles-0]

Lastly, do raycast, webrtc and websocket offer something on top of what has already been made in the engine? Are they safe to disable?

[Calinou]

Lastly, do raycast, webrtc and websocket offer something on top of what has already been made in the engine? Are they safe to disable?

The raycast module is also used in the lightmapper only, and isn't used anywhere else. webrtc and websocket are generally only useful if your project intends to use networking with HTML5 clients (which can't use raw UDP packets).

[themistocles-0]

Thanks for the help

[Calinou]

Reopening, as this should still be documented (to an extent) on the Optimizing for size page.

[Xrayez]

See a list of modules with dependencies at:

• https://github.com/godotengine/godot/issues/39196

Those modules that are not meant to be disabled should be automatically enabled in my opinion. And every build issue relating to disabling a module should be considered a bug. So there's not much to document here I think.

[themistocles-0]

I haven't seen any detailed explanation on the modules anywhere, could we get a tree or description that details what depends on what, the core engine features that are lost when disabling certain modules, the list of issues shown above is quite long, and most of the time these crashes or wierd behavior happen depending on your development environment i.e: your linux distribution, libraries you've installed. It would be better to have a centralized description of what is in the engine, and what it does, rather than module related issues strewn about to look through.

[Xrayez]

@JoshuaAudreyMudanyi I'd say usage of modules in Godot is monolithic to some extent. Godot is described as an end product, not as a collection of libraries. Modules are seen more like implementation detail that advanced users could configure. What I say does not mean that those modules cannot be documented individually, just explaining why they are not fully documented as of now.

If I were in charge to decide how modules could be configured and organized, I'd definitely refactor and rewrite some of this.

If you look at Goost documentation, that's a whole different story there, because I've made Goost to look more like a library for Godot. This is definitely not the case with Godot, unless modules may be ported to GDExtension.