Quixel materials in Godot
Been testing Quixel Megascans surfaces in Godot to see if they’d hold up without an Unreal-grade material graph doing the heavy lifting. Short answer: yes, once the import pipeline is set up right.
Getting the textures out of Bridge
Bridge has a Godot export preset now, which saves a step — it outputs:
- Albedo (color)
- Normal (tangent-space)
- ORM — Occlusion, Roughness, and Metallic packed into one texture’s R/G/B channels
That ORM packing matters. Godot’s StandardMaterial3D has a dedicated ORM texture slot that expects exactly that channel layout, so instead of wiring up three separate grayscale maps you drop in one texture and it splits itself out.
Import settings that actually matter
- Albedo stays sRGB — it’s color data.
- Normal and ORM get imported as raw/linear, not sRGB — they’re data, not color, and importing them as sRGB washes out the roughness response and flattens the normal map.
- Normal map import mode set explicitly to “Normal Map” so Godot doesn’t try to guess and get it wrong.
- 8K source scans get downsized to 2K (occasionally 4K for hero surfaces) and compressed with VRAM Compressed — full-res Megascans textures are built for offline render farms, not a real-time budget.
The wall test
The panel in the screenshot below is one of the rusted corrugated metal scans, applied straight to a test wall with no custom UVs — just triplanar mapping turned on in the material so it doesn’t stretch across the seams. At in-game distance, under Godot’s Forward+ renderer, the ORM roughness response alone sells the material; you don’t need much else on top of it.
Verdict
For static architecture — walls, panels, industrial surfaces — Quixel scans drop into Godot with almost no extra work beyond the import settings above. Where it gets more involved is anything that needs to deform or blend (terrain, damage decals), which is a separate problem for a separate post.