Allow building the editor with 3D disabled, or without 3D Physics/Navigation.

[WhalesState]

Allows building the editor using disable_navigation_3d=yes, disable_physics_3d=yes or disable_3d=yes.

• Discussion: Allow Building the Editor with 3D disabled godot-proposals#12305

I just have submitted my answers for Godot Community poll, noticing that the majority of Godot users focus on 2D games and GUI applications, but yet only 6% are recompiling the engine so I do agree that the cost is more the benefits, but it worth to be updated for those who needs it and until many users be familiar with building 2D templates.

Size Comparison: https://github.com/mounirtohami/godot/actions/runs/16565434882

[syntaxerror247]

I’m not sure I see the need for this. Why would you want to build the editor with 3D disabled? It doesn’t offer any real advantage for final projects, since those can already be built without 3D. This change just adds unnecessary checks in the editor code without a clear benefit.

I’d recommend creating a proposal to clearly explain the motivation and potential benefits before moving forward with this PR.

[WhalesState]

I’m not sure I see the need for this. Why would you want to build the editor with 3D disabled? It doesn’t offer any real advantage for final projects, since those can already be built without 3D. This change just adds unnecessary checks in the editor code without a clear benefit.

I’d recommend creating a proposal to clearly explain the motivation and potential benefits before moving forward with this PR.

• Faster builds and smaller binaries: This enables indie developers and contributors targeting 2D-only projects to build the editor faster and generate smaller binaries, reducing complexity. It’s especially valuable for Android editor builds and other constrained environments. It also helps ensure that internal documentation and class listings reflect only the available 2D features, giving users a clearer view of what they can actually use when 3D is disabled.

• Cleaner and more focused UX for 2D developers: Currently, 3D features are only hidden via the feature profiler, they're still loaded, which adds overhead. With proper 3D disabling at the build level, developers can launch the editor into a truly 2D-focused mode. This improves usability, reduces distraction, and speeds up iteration. It's also a step toward fully disabling 3D drawing methods in the RenderingServer, which will further optimize the workflow for 2D game development.

• Reduced memory and resource usage: From past experience working on this, I’ve seen firsthand how disabling 3D can significantly lower memory consumption, making the editor more viable on low-spec machines or mobile setups. This can position Godot more favorably when compared to other lightweight 2D engines.

• Improved modularity and maintainability: This direction aligns well with Godot’s modular architecture. Adding clean, optional 3D support at the editor level increases the engine’s flexibility and opens the door to more specialized editor builds in the future.

This is not just about removing 3D, it’s about giving developers more control over their tools, improving performance, and reducing unnecessary overhead when it’s not needed.

[syntaxerror247]

@WhalesState this is a significant change, it needs a proper proposal.

[WhalesState]

@WhalesState this is a significant change, it needs a proper proposal.

I understand your concerns, and I'd like to link the PR when it's finished to the proposal if no one ever proposed it.
If you are worry about the conflicts that it may cause then don't worry, using #ifndef rarely causes conflicts.

And it's not significant yet, just one more commit to allow building with disable_3d=yes and I'm done with it then will open a proposal :).

[scgm0]

I’m not sure I see the need for this. Why would you want to build the editor with 3D disabled? It doesn’t offer any real advantage for final projects, since those can already be built without 3D. This change just adds unnecessary checks in the editor code without a clear benefit.

I’d recommend creating a proposal to clearly explain the motivation and potential benefits before moving forward with this PR.

For projects using C# but not 3D, it offers some advantages: the C# bindings are generated by the editor, which cannot disable 3D. This means C# will inevitably generate bindings related to 3D, leading to certain issues after export. For example, GetViewport() cannot be used because the C# Viewport has bindings for the World3D property, but the export template lacks both the World3D property and the World3D class, triggering a C# exception.

[AThousandShips]

The C# side is something that should probably be fixed by other means rather than tweaking the editor, especially since you might want to build different versions of the bindings for different exports etc., and there's various other things you can't disable for the editor and that likely won't ever be possible to disable for the editor (like advanced UI)

[WhalesState]

The C# side is something that should probably be fixed by other means rather than tweaking the editor, especially since you might want to build different versions of the bindings for different exports etc., and there's various other things you can't disable for the editor and that likely won't ever be possible to disable for the editor (like advanced UI)

I can find a workaround for the advanced gui but it's not related to this change, we have a real issue that you just said it should be fixed, and soon it will :)

[Delsin-Yu]

See #103315
See also https://chat.godotengine.org/channel/dotnet?msg=CtWM33pz3qMNJx2qb

@WhalesState

I agreed that this PR adds too much complexity and maintenance cost if the reason is just for C# bindings generation. The editor feature profile can already cover the need to disable certain editor features, and the pursuit of the minimum export template size doesn't need the editor stripped anyway.

If anyone wishes to fix the C# bind-gen issue, I would recommend implementing such functionality directly in bindings_generator.cpp rather than stripping the whole editor (this also gives more flexibility).

[AThousandShips]

You shouldn't have to build the editor with all the different configurations you want for any specific export template, that's not really fixing any issue, so I think it's best to not focus on the C# bindings side and instead focus on the need and demand for this specific editor build (it's enough work to keep a few different export templates around for each platform + configuration)

[syntaxerror247]

This PR is starting to attract some discussion and it's the exact reason, I wanted it to have a proposal attached. So, it can be discussed properly.

[WhalesState]

This PR is starting to attract some discussion and it's the exact reason, I wanted it to have a proposal attached. So, it can be discussed properly.

Please do, I'm the less experienced one here and I'm just adding some #ifndef lines to the editor so I'd like to hear from more users who works on 2D games, and more users who are affected by the C# issue, if it fixes a single bug that no one tries to fix then it worth to be discussed, It's also shouldn't be called complex changes because it's just some #ifndef lines that will harm no one, yes it will cause conflicts but they can be easily fixed, just let me finish it and we see how it goes, I'm sure many users will like this change, and especially those who uses the godot editor on android and those who uses Godot for 2D games only, they really deserve a lighter and faster editor.

[Delsin-Yu]

Please do...

You can then open the proposal in https://github.com/godotengine/godot-proposals and link it to this PR.

[scgm0]

Someone asked what benefits this PR would bring. I listed the C# example, but you guys said C# should use a better solution and not expect this PR. Hmm, alright, after all, I might be the only one here who's been troubled by that issue for months.
A better solution has already been implemented in the godot-dotnet repository, but it's unrelated to the current godot-sharp. I also desire a superior approach, but it seems unlikely to be realized in the short term. Therefore, I can only pin my hopes on this PR's temporary fix—after all, a stopgap measure is better than no solution at all.

[MewPurPur]

What's the benefit of this compared to disabling the 3D-specific editor features, which even seem to have a "2D Profile" ready to go? (unless I added the 2D profile and forgot)

[AThousandShips]

Let's wait with any further discussion until we have a proposal to not bog this down in off topic

[WhalesState]

Hello @aaronfranke, I resolved the requested changes five days ago. Could you please dismiss the review? You also can approve it but I don't expect it to be merged any where soon, Just let me know if there’s anything else needed. Thank you!

[AThousandShips]

If you want the files moved in the editor to be part of this change I'd suggest opening a separate PR as it's far more unlikely to get that merged in 4.6 and later given how disruptive it is, but the window for restructure in 4.5 as a follow-up to my restructure is still open, see:

• Move 2D and 3D particle editors to the 2D and 3D folders #108368

[WhalesState]

Thank you, I will open a PR with the last 4 files that are related to 3D, but for the 22 files related to physics gizmos I don't know if they should be changed now or to be kept inside this PR until the team gets time to review the changes.

[AThousandShips]

I'd say they have a very low chance of being approved for move once 4.5 is released, we prefer one noisy period, so I'd say either they should be moved now or not for a long while (a minor version at least, so not in 4.6)

[fire]

@aaronfranke has been working towards this with the move to folders. So I think there is some interest from the other maintainers. I think that it isn't possible to disable 3d due to 3d rendering architecture but we can definitely disable code that is specially 3d related or 3d physics etc.

[WhalesState]

@aaronfranke has been working towards this with the move to folders. So I think there is some interest from the other maintainers. I think that it isn't possible to disable 3d due to 3d rendering architecture but we can definitely disable code that is specially 3d related or 3d physics etc.

Much thanks to all the Godot developers!
I'm leaving this here as a reference since it shows all the code that needs to be disabled. However, I’m not a fan of how some if statements are split into three lines, this happens more than once within the same class, leading to redundant code.

I'd prefer to wait until the team has time to review it properly, and I’d really appreciate it if someone could co-author or collaborate on this.

[aaronfranke]

Prefer modern C++ using to avoid polluting the global preprocessor namespace.

Suggested change

	#define Shape3D RefCounted
	using Shape3D = RefCounted;