Godot 4.7.2 shipped August 18, 2026 with a fix for GH-120774: PCSS soft shadows from `DirectionalLight3D` were computing blur size from the shadow map's world-space position instead of the camera's view space. In plain terms, the same object cast a different amount of shadow blur depending on how far it sat from world origin `(0, 0, 0)`. Move a prop 500 meters out and its penumbra visibly changed even though nothing about the light or the object changed. The fix subtracts the camera origin from the range-begin calculation, and the Godot team is direct about the tradeoff: your existing scenes' blur amount may look different after upgrading, because the old behavior "never worked correctly in the first place."
That's the one line in a 57-fix maintenance release worth stopping for if you're running PBR-lit GLB imports in Godot.
The bug: shadow blur pinned to world origin, not your camera
The underlying issue, #86536, sat open for a while before contributor blueskythlikesclouds shipped the fix in June and it got cherry-picked into 4.7.2 on July 24. PCSS uses a "shadow range begin" value to figure out how far into the shadow map a given vertex sits, which drives the blur radius. That value was carrying the projection of the shadow map center in world space, but the shader was doing its blur math in view space. Two coordinate spaces, one calculation, mismatched.
Practical effect: place a model like the Floating Tavern Island near map center and its directional-light shadow looks tight and grounded. Duplicate it out at the edge of a large level and the same light, same angle, same blur settings produce a visibly softer, smearier shadow — because the math was quietly keying off distance from `(0,0,0)`, not distance from camera or light. Any project with a large play space, an open-world layout, or props scattered well outside the origin was seeing this without knowing why. After 4.7.2, blur is view-consistent: same distance-to-camera, same softness, regardless of where the object sits on the map.
If your project only ever sat within a tight radius of world origin, you likely never noticed. If you've got a sprawling outdoor scene or you stream in chunks far from `(0,0,0)`, expect your directional shadows to look different the moment you upgrade — screenshot before you update the engine version in CI so you have something to diff against.
Every fix in Godot 4.7.2, and what actually touches your assets
39 contributors landed 57 fixes total. Most are editor polish or platform-specific input handling that won't touch a GLB pipeline at all. Here's what's actually relevant if you ship 3D assets:
| Fix | Area | Matters for asset work if... |
|---|---|---|
| PCSS shadow range in wrong space (GH-120774) | Rendering | You use `DirectionalLight3D` + PCSS on a scene larger than a small radius around origin |
| Single main thread enforced, no unnecessary release (GH-121161) | Core | You've written a custom `GLTFDocumentExtension` or import plugin that touches threads |
| High-polling-rate mouse lag on Windows (GH-109639) | Input | You're doing viewport gizmo work or manual UV editing at a high mouse poll rate |
| mbedTLS always uses Godot's OS entropy source (GH-121759) | Network | You pull remote assets or use the AssetLib during import |
| Crash opening log file for writing (GH-121926) | Core | You batch-import large asset libraries in CI and rely on logs surviving a crash |
The threading fix is the one to read twice if you write editor tooling. It doesn't change any documented API — `GLTFDocumentExtension` classes are still required to be stateless, same as always — but it hardens the engine against exactly the kind of subtly-wrong concurrency pattern that produces a crash six months later instead of an error today. If your import pipeline has custom postprocessing that spawns worker threads or touches editor state off the main thread, 4.7.2 is more likely to catch it loudly than 4.7.1 was.
Should you upgrade a GLB-heavy project today
Godot's own release notes report zero known incompatibilities against 4.7.1, and they're recommending the upgrade to everyone. That claim holds for the vast majority of projects. The one exception worth budgeting fifteen minutes for: open a scene with `DirectionalLight3D` and PCSS shadows enabled, place a test object at origin and another 200+ meters out, and compare shadow softness before and after the upgrade. If your project has already been fighting with the red X on reimported GLB files after a clean checkout, do that reimport pass in the same sitting — a version bump is the moment those import cache issues tend to surface anyway.
Godot's shadow softness settings live under Directional Shadow on the light node's Inspector, specifically Blur under the PCSS group — that's the parameter whose visual result just changed. If you're also tracking Godot's `.godot` import diffs in version control the way 4.8's dev builds now make readable, the shadow atlas settings aren't part of that diff — this is purely a runtime shader calculation, not an import-time change, so nothing in your `.import` files will show the difference. You'll only catch it by looking at a rendered frame.
For texture-heavy assets riding into the same scenes, the shadow calculation is independent of whichever texture compression path you're using for GLB imports — KTX2 or otherwise. This fix touches the shadow map sampling stage, not material or texture loading, so you won't see any interaction there. It's a shader-math correction, isolated to one light type and one shadow technique, which is exactly why it's a safe upgrade for everyone except the specific case of large scenes where the old, broken behavior was accidentally doing something a scene happened to rely on.
Download 4.7.2 from the official archive, and if you hit anything the release notes didn't predict, the Godot team is explicitly asking for bug reports on GitHub — they want the regression reports if the "zero incompatibilities" claim turns out to have an edge case.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*