Why Does My Godot 3D Scene Look So Dark?

Your level looks readable in the 3D editor. Press Play and the walls turn almost black. Before increasing every light, check whether the editor and the running game are using the same lighting and camera settings. Then narrow the problem to the whole scene, its shadowed areas, or one material.

Does it only go dark when you press Play?

Godot can show preview sunlight and a preview environment when the scene has no corresponding nodes. Those previews help you work in the editor; they do not light the running or exported game. Toggle the preview sun and environment off in the 3D viewport toolbar and compare again.

If that reproduces the darkness, add an actual DirectionalLight3D and a WorldEnvironment with an Environment resource to your scene. Save it and run the same scene again. This is the distinction raised in a Godot 4.0 reader question from 2023; the current editor documentation still describes the preview behavior.

Also confirm which scene you launched. A light in a parent level will not be present when you run an isolated child scene. In the running game’s Remote scene tree, check that the light and environment you edited actually exist.

Choose the symptom before changing a value

• Everything is dark, including a plain test sphere: inspect the active light, environment, and camera settings.
• The lit side looks fine but shadows are black: compare ambient illumination while leaving the direct light unchanged.
• Only the imported model is black: compare its material with a fresh StandardMaterial3D before adjusting the whole level.
• Brightness changes when the camera moves: check automatic exposure and camera-specific overrides.
• It changes after switching renderer or exporting: compare the same scene and record which lighting features are available on the target.

Keep a copy of the scene before the investigation. Use one camera position and change one setting per run. Write down what changed on the lit side and the shadowed side separately; “it looks brighter” can hide the fact that the highlights are now blown out.

Use a plain sphere to test the light

Create a separate scene named LightCheck.tscn with a Node3D root. The tree below is a small diagnostic setup, not a replacement for your level. Use a fresh project with the default non-physical light units if your production project has a physical-camera setup you do not want to disturb.

Run the scene, then hide Sun and run it again. With ambient energy at zero and the plain material, expect a clear change on the side facing the light. These values are suggested starting settings for this comparison, not measured brightness targets. If nothing changes, check that you edited the running scene and that the material is shaded.

A DirectionalLight3D is controlled by its direction. Moving it closer to the sphere does not bring a lamp closer; rotate it to change which side receives light. For an OmniLight3D or SpotLight3D in your real level, inspect its range and, for a spotlight, its cone. Increasing Energy does not increase the light’s range.

If one mesh ignores an otherwise working light, compare the light’s Cull Mask with the mesh’s visual layers. These are rendering layers, separate from physics collision layers. Temporarily disable shadows in the test copy to check whether geometry is blocking the direct light, then restore them.

The lit side is fine, but the other side is black

With Sun enabled, change the test environment’s Ambient Light Energy from 0.0 to 0.25, keeping Source set to Color and its color white. Watch the side facing away from the light. If it becomes readable, you have identified missing fill in this setup. Decide how much contrast the level needs before raising it further.

A visible background and ambient illumination are separately configurable. For a sky-based setup, assign a Sky resource with a sky material and choose Sky as the ambient source. Reflected Light has its own source setting too. A background color alone is not enough information to diagnose what an object receives.

Use the lighting and materials experiment to compare color ambient with a sky and reflections. If you need bounced light that responds to room geometry, continue to the global illumination explanation. The constant-color test here is useful for diagnosis, but it does not model light passing through a doorway.

Only my imported model looks black

Put the plain sphere next to the model. If the sphere responds to Sun, assign a new neutral StandardMaterial3D to the model’s Material Override in a copy of the scene. Leave Metallic at 0 and texture slots empty for this check.

If the model becomes readable, restore its material inputs separately. Check the albedo color as well as its texture: they multiply. A dark color can dim an otherwise bright texture. Check Metallic next. Metallic surfaces rely more on reflected light and receive less diffuse contribution, so a material exported with the wrong metallic values can look very different.

Try Unshaded on the temporary material as another comparison. If it becomes visible, investigate lighting and shading inputs. If it is still absent, check camera framing, visibility, and mesh geometry too. Neither result proves that one particular texture or normal is the culprit.

If editing one material changes several objects, inspect whether they share the Resource. The shared Resources troubleshooting section shows a small reproduction. Keep the diagnostic material separate so the test does not recolor the rest of your level.

Why do WorldEnvironment changes seem to do nothing?

Inspect the current Camera3D. An Environment assigned there takes priority over WorldEnvironment. Camera attributes can also be assigned in both places, with the camera’s attributes taking precedence. Compare the active resources before adding another WorldEnvironment node.

In the test copy, leave Camera3D’s Environment empty so you can work on the WorldEnvironment resource deliberately. Keep a record of any override you remove. In the production scene it might be intentional, such as a different view used for a cutscene.

Check exposure before adding more lamps

Use CameraAttributesPractical for the simple comparison above. Set Exposure Multiplier to 1.0 and turn automatic exposure off. Automatic exposure is supported in Forward+; it is not available in Mobile or Compatibility. Keep the camera still while comparing the result.

If the brightness previously drifted as the view changed, repeat that movement with automatic exposure disabled. A change in behavior points you toward the camera settings. Exposure affects the captured image; raising it can brighten existing highlights without fixing an area that receives no useful illumination.

A project using CameraAttributesPhysical needs a separate review of its physical exposure settings. Avoid copying arbitrary energy values from a non-physical example into that project. Record the camera resource, light-unit setting, and renderer with the comparison so the numbers have context.

It went dark after I changed renderer

Check the feature you were relying on. SDFGI, VoxelGI, and SSIL are supported in Forward+ but not Mobile or Compatibility in the documentation reviewed here. Switching methods can remove the indirect contribution your scene depended on. Compare direct light and the plain material first, then review the unsupported effects.

The renderer comparison explains those tradeoffs. If the difference appears only in a browser build, use the web-export guide to distinguish a rendering problem from missing files or shader errors. Keep the same camera and scene revision in both runs.

Keep the comparison that found the cause

Write a short note with the symptom, the single setting you changed, and what happened. For example: “The editor was brighter because it used preview sunlight; adding Sun to the running scene restored direct lighting.” That is an example report, not a claim about your project.

• Run the actual level, not only LightCheck.tscn.
• Restore the shadows and materials you temporarily removed, checking the image after each step.
• Compare the dimmest playable area and the brightest highlight from the game camera.
• Keep a before-and-after capture with the Godot version, renderer, and changed setting noted.

Once the cause is clear, continue building the playable 3D room. Judge the lighting while moving through it: the player still needs to see the floor edge and obstacles from the camera angles the game actually uses.