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

[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]

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)

A benchmark will tell the difference, the editor should load faster and will consume less memory, and should render 2D scenes faster since we have skipped all the Viewport Renderer 3D code, you will also open the docs and you will see all the classes and methods you can use when you build the templates with 3D disabled, disabling 3D from the editor profile is just hides things, there is no proper disable for 3D in editor.

[Delsin-Yu]

So in short:

1. Faster Editor Startup. (require benchmark numbers)
2. Better 2D Performance in Editor & Editor Run Mode. (require benchmark numbers)
3. Compile-time validation on accidental use of disabled 3D features.

At the cost of:

• Additional #ifndef directives in the source code lead to increased maintenance efforts.

[AThousandShips]

Also the lightmapper_rd module needs to be disabled on non-3D builds, so:

diff --git a/modules/lightmapper_rd/config.py b/modules/lightmapper_rd/config.py
index ecc61c2d7e..e18d288753 100644
--- a/modules/lightmapper_rd/config.py
+++ b/modules/lightmapper_rd/config.py
@@ -1,5 +1,5 @@
 def can_build(env, platform):
-    return env.editor_build and platform not in ["android", "ios"]
+    return not env["disable_3d"] and env.editor_build and platform not in ["android", "ios"]


 def configure(env):

[WhalesState]

At the cost of:

• Additional #ifndef Directives in source code.

The same thing goes for export templates, it's all over the engine. I'm preparing a benchmark to see the difference, just waiting for editor to build with same flags, if it worth it then we can discuss it, if it doesn't then i have no issues to keep it open for anyone who needs it.

[AThousandShips]

Again, please create a proposal and discuss this further there, this is getting cluttered with off topic discussions

[AThousandShips]

So from compiling this there's a few immediate issues:

• The Export As... -> Mesh Library option fails as it depends on 3D features
• Creating a Sky and trying to add a new material for it fails as the required materials are missing
• Creating or using materials for CanvasItem throws ERROR: Condition "p_texture.is_null()" is true. errors, seems some rendering features are not working correctly with this setup (doesn't happen without this PR)
• The "Manage Editor Features" menu still shows "3D Editor"

That was all I tested right now, but there's a lot to test and fix here just from this brief test, so this will need very extensive testing to make sure it works correctly

For savings, the editor executable is about 30 MB smaller, which is a pretty neat reduction in space

A basic benchmark doesn't show any reliable differences in performance that I can see, but did just a very basic one, so that would need a more detailed test over several runs, but nothing sticks out there

[WhalesState]

🧪 Godot Editor Benchmark Comparison: 3D Disabled vs Enabled

⚔️ Summary Table

Section	3D Disabled	3D Enabled	🔍 Difference & Notes
Main::Start	6041.822 ms	7398.241 ms	+1356 ms – Overall startup slower
Editor	5967.604 ms	7329.662 ms	+1362 ms – Heaviest slowdown here
Main::Setup2	1916.143 ms	2146.563 ms	+230 ms
Servers (Startup)	1442.803 ms	1594.149 ms	+151 ms
Scene (Startup)	301.489 ms	327.418 ms	+26 ms
Display Server	1165.205 ms	1265.940 ms	+100 ms – More GPU init time
Rendering	85.439 ms	103.915 ms	+18 ms – More rendering setup
Register Scene Types	119.242 ms	146.132 ms	+27 ms
Editor Modules/Ext.	0.058 ms	0.415 ms	+357% – Extra modules for 3D loaded
Theme: Icons	402.771 ms	413.973 ms	Slight increase – more icons maybe?
Theme: Fonts	93.721 ms	91.059 ms	Minor fluctuation
Create Base Theme	974.966 ms	973.913 ms	Almost identical

---

The editor loads faster by ~3.35 seconds with 3D disabled.

[AThousandShips]

I can't replicate these benchmarks reliably, it varies more between runs of the same configuration than it does between configurations, but I'll set up some runs later and run several times averaging more carefully

Though it's hard to even say if these benchmarks are useful since the editor doesn't work currently, and the data might be very different when the various bugs have been fixed

[WhalesState]

Fixed all the above issues, for Sky resource, the issue is related to the property hint.

ADD_PROPERTY(PropertyInfo(Variant::OBJECT, "sky_material", PROPERTY_HINT_RESOURCE_TYPE, "PanoramaSkyMaterial,ProceduralSkyMaterial,PhysicalSkyMaterial,ShaderMaterial"), "set_material", "get_material");

[AThousandShips]

Note that this does not close godotengine/godot-proposals#12106 as that's specifically about decoupling the bindings from the editor, even though this solves the problem that proposal aims to solve it isn't a solution to it as per the reasons mentioned above

It'd be like linking a PR that adds a method to write a plugin to solve something when the proposal is about adding an editor feature to perform the solution, it solves the goal (and only partially) but not the intention (and again other configuration details that can't be done with editor changes, or at least not this PR)

[WhalesState]

Opening a Proposal requires me to write the issue that it solves, and i didn't test if it fixes the C# issue, and how it's going to affect GDExtension if we dump the api with 3d disabled.

Also all the changes are meant to be editor changes, but i have found other issues and fixed them for GridMap, AudioStreamPlayer3D, SceneDebugger and World3D.

[AThousandShips]

Again let's focus on the benefit for the editor by disabling this, not potential C# things it tangentially solves, but it would be good to have a proposal going because it's pretty critical to be able to assess if this is actually needed

[WhalesState]

The benefit for me is that it will help us to make a better 3d_disable for templates and be able to test 2d projects in editor by just opening and running them instead of exporting every project with the new templates.

Edit: You will also be able to run the projects from project manager which is much faster.