What causes shadows not rendering on a realtime directional light?

A directional light renders no shadows when its shadow type is set to none, shadow distance is zero, the quality tier disables shadows, or receivers are not set to receive.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix Shadows Not Rendering on a Realtime Directional Light

Quick answer: Set the light's shadow type to soft or hard, raise the shadow distance above zero, enable shadows in the quality settings, and confirm objects cast and receive shadows.

No directional shadows is almost always a disabled setting, not a bug. Turning on the light's shadows, a non-zero distance, and quality-tier shadows brings them back.

How to fix it

1. Enable shadows on the light

Set the directional light's shadow type to hard or soft rather than No Shadows; this is the most common reason a sun casts nothing.

2. Check shadow distance and quality

Ensure the project's shadow distance is greater than zero and the active quality level has shadows enabled, since a low quality tier can switch them off entirely.

3. Verify cast and receive flags

Confirm the casting meshes have cast-shadows enabled and the ground/walls are set to receive shadows; a disabled flag on either side hides the result.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Most of the time the fix is small. Seeing the failure clearly is the part that actually costs you.