CD Projekt Red ditched REDengine for The Witcher 4, but tools aren’t the whole story

The Witcher 4 and the End of REDengine

Executive Summary: CD Projekt Red’s migration from REDengine to Unreal Engine 5 for The Witcher 4 rewrites the studio’s asset pipelines, automation layers, and rendering targets. The shift introduces measurable improvements in world-building tooling, build validation, and geometry throughput, but it does not automatically resolve the content scope, management discipline, and quality-assurance throughput risks that defined Cyberpunk 2077’s development. Co-CEO Michał Nowakowski acknowledges the studio has not fully achieved a redemption arc following that release. The engine change is a necessary infrastructure decision with clearly bounded benefits.

CD Projekt Red spent more than a decade refining REDengine across The Witcher 2, The Witcher 3: Wild Hunt, and Cyberpunk 2077. That codebase was purpose-built for narrative RPGs with bespoke rendering features, custom world-editing tools, and proprietary asset formats. Moving The Witcher 4 to Unreal Engine 5 is not a simple renderer swap. It is a ground-up reconstruction of how the studio builds, validates, and ships content. The practical effects fall into two categories: pipeline mechanics that change immediately, and organizational constraints that remain untouched.

The partnership with Epic Games, announced alongside the new Witcher saga, includes direct engineering collaboration. That relationship matters because UE5 is not an off-the-shelf product for a studio accustomed to modifying every layer of its technology stack. CD Projekt Red will need custom plugins, toolchain extensions, and potentially engine source modifications to replicate workflows that were hardcoded into REDengine. Epic’s involvement reduces the risk of those modifications becoming unsupported forks, but it does not eliminate the migration cost. Every procedural weather system, every custom cutscene tool, and every narrative scripting layer must be rebuilt or replaced.

Pipeline Shift: REDengine vs. Unreal Engine 5

Pipeline Component	REDengine Legacy	Unreal Engine 5 Target State	Practical Impact on The Witcher 4
Static Geometry	Manual LOD0-LOD4 chains, proprietary mesh format	Nanite virtualized geometry, RTX Mega Geometry for ray-traced LOD	Eliminates manual LOD authoring for dense environments; shifts forest-scene fidelity
World-Building Automation	Bespoke editor scripts, limited batch processing	PCG framework, automated foliage and prop placement, batch terrain and decal processing	Faster iteration on large biomes; reduced manual placement time
Material Authoring	Custom shader pipeline tailored to REDengine	UE5 Material Layering, Substrate shading model	Requires complete asset re-authoring; standardizes cross-project workflows
Animation & Rigging	Custom middleware and retargeting tools	Control Rig, IK Rig, Motion Matching	Reduced per-character setup time; standardized retargeting
Build Validation	Limited automated reference and collision checks	Native reference validation, automated collision auditing, established CI/CD ecosystem	Earlier detection of broken references and bad collision before shipping builds
Performance Baseline	Variable parity across PC and last-generation consoles	60 frames-per-second target on base PlayStation 5	Console-first optimization ceiling; constrained PC feature headroom

Asset Iteration and World-Building Automation

The most immediate impact of the Unreal Engine 5 migration is visible in asset iteration and world-building tooling. REDengine’s workflow required artists to construct manual level-of-detail chains for static meshes, author materials in a proprietary shader language, and place dense foliage and props largely by hand or through limited scripting. The shift to UE5 replaces that framework with Nanite for virtualized geometry, which removes the traditional LOD pipeline for static assets and allows film-source art to drop directly into the engine without polygon budget anxiety. For a project like The Witcher 4, which targets large natural environments including forests, that change alters how environment artists work. Kitbashing becomes faster because modular pieces no longer need bespoke LOD transitions authored per asset.

World-building automation expands beyond Nanite. UE5’s Procedural Content Generation framework, combined with Python scripting and Blueprint tooling, supports automated placement tools for foliage and props, validation checks for broken references or bad collision, and batch processing for terrain, decals, and materials. These are not cosmetic conveniences. In a dense open world, manual placement scales linearly with team size, while automated scattering and validation scale with code. REDengine’s tooling required CD Projekt Red to maintain custom solutions for these problems. UE5 provides standardized systems that have been battle-tested across dozens of shipped titles, reducing the maintenance surface area for the studio’s internal technology team.

Foliage automation specifically alters the density-to-performance equation. In REDengine, artists placed vegetation by hand or through limited noise-based scattering, then manually tuned culling distances and LOD switches to stay within memory budgets. UE5’s automated placement tools, paired with Nanite, allow higher instance counts with less manual tuning. The validation layer-automatic checks for floating props, overlapping collision, or missing physical materials-catches errors that previously required loading a level and walking the space. That shift moves quality control left in the production timeline, from level-review meetings to automated build reports.

Material authoring undergoes a similar standardization. REDengine’s custom shader pipeline meant that every material definition was studio-specific knowledge. Migrating to UE5’s Material Layering and Substrate forces a re-authoring pass on existing assets, which creates short-term friction. The long-term tradeoff is interoperability: external contractors, new hires, and outsourced art houses can work in a standardized environment without learning a proprietary node graph. For a project of The Witcher 4’s expected scope, that flattening of the learning curve affects hiring velocity and outsourcing reliability.

Animation, Rigging, and Build Reliability

Animation and rigging pipelines in REDengine relied on custom middleware that CD Projekt Red maintained internally. UE5 replaces that stack with Control Rig for in-engine animation authoring, IK Rig for universal retargeting, and Motion Matching for locomotion systems. The practical result is reduced setup time per character. In REDengine, a new creature or NPC required custom rigging solutions and retargeting scripts that lived only inside CD Projekt Red’s walls. UE5’s retargeting standards allow motion capture data and gameplay animations to move across skeletons with less manual intervention. That does not automatically produce better animation; it reduces the technical barrier between raw data and in-game implementation.

Build and release reliability represent another concrete improvement. Cyberpunk 2077 shipped with visible broken references, floating geometry, and collision errors that suggested late-stage build instability. UE5’s native cooking pipeline includes reference validation that catches missing assets before a build completes, and the engine’s broader ecosystem includes established continuous integration and deployment practices. Automated checks for bad collision, dangling pointers, and malformed terrain layers can now run as part of nightly builds rather than relying on manual spot checks. This addresses one of the specific failure modes visible in Cyberpunk 2077’s launch build: not merely bugs in gameplay logic, but broken asset packaging that manifested as crashes on PlayStation 4 and Xbox One.

RTX Mega Geometry and the 60 FPS Console Target

The Witcher 4 is targeting 60 frames per second on the standard PlayStation 5. That constraint dictates every rendering decision the team makes. Unreal Engine 5 provides scalable features-Lumen global illumination and Nanite both have platform-specific quality tiers—but hitting 60 FPS in an open-world RPG on base console hardware still requires aggressive optimization. CD Projekt Red has indicated that console parity is the lead platform priority, which implies PC-specific features may not drive development. Historically, the studio emphasized advanced PC graphics settings; under UE5 with a console-first mandate, ultrawide support, raw renderer toggles, and uncapped feature sets may follow console limitations rather than lead them.

The 60 FPS target on base PlayStation 5 also has implications for the PC version’s scalability. REDengine titles historically pushed PC hardware aggressively, sometimes at the expense of console stability. By leading with console performance, CD Projekt Red signals a reversal: the game must run smoothly on fixed hardware first, then scale upward. That approach reduces the likelihood of the base-console crashes that marred Cyberpunk 2077, but it may disappoint players expecting a generational PC showcase that ignores console constraints. Whether the PC version receives dedicated high-end features—higher Nanite detail tiers, uncapped Lumen quality, or advanced ray-tracing presets—depends on whether the team maintains separate optimization tracks after the console build is locked.

Within that performance envelope, Nvidia’s RTX Mega Geometry enters the pipeline. The technology is a geometry and LOD system designed for ray tracing at large scale, updating scenes up to 100 times faster than prior ray-tracing traversal methods by restructuring how level of detail and ray traversal interact. Forest environments, which are traditionally expensive for ray tracing due to overlapping translucent geometry and high instance counts, are the stated use case. Alan Wake 2 includes support for the technology, and The Witcher 4 is planned as a future title that will use it. The caveat is that the 100x speedup describes scene-update throughput for specific traversal scenarios, not a blanket multiplier for every frame. Real-world fidelity gains depend on how CD Projekt Red integrates the tech with UE5’s existing Nanite and Lumen pipelines, and how aggressively the base PS5 target limits ray-traced effects.

The interaction between RTX Mega Geometry and UE5’s existing Nanite pipeline is critical. Nanite handles rasterization of dense geometry; RTX Mega Geometry handles the ray-traced equivalent by providing a unified LOD acceleration structure that updates rapidly as the camera moves through complex scenes. Without this, tracing rays through a forest would require either conservative bounding volumes that miss detail or high-update-cost structures that consume frame time. The technology does not remove the base cost of ray tracing, nor does it guarantee that The Witcher 4 will ship with full-scene ray tracing enabled on console hardware. It simply makes the option computationally feasible on high-end hardware without requiring artists to maintain separate ray-tracing LOD chains alongside Nanite’s virtualized geometry.

What the Engine Swap Does Not Fix

Pipeline improvements are not project improvements. Unreal Engine 5 gives CD Projekt Red faster tools, but it does not impose discipline on content scope, milestone scheduling, or management throughput. Cyberpunk 2077’s development was marked by feature creep, late-scope changes, and systemic design issues that tooling alone cannot prevent. An engine swap does not rewrite production calendars. It does not prevent quest logic from becoming convoluted, nor does it guarantee that narrative branching will stay within QA capacity.

Content scope risk deserves emphasis. Cyberpunk 2077’s development suffered from a gap between the vertical slice and the final open world, a problem that better engine tools can actually worsen. When environment artists can populate a forest faster, the temptation is to build more forest than the narrative or quest design can support. Tooling efficiency without design restraint produces larger, emptier worlds. UE5 has no built-in limiter for world size or quest density; those remain creative and managerial decisions.

Quality-assurance throughput illustrates the boundary clearly. Automated validation checks catch broken references and bad collision, which are technical errors. They do not catch quest progression breaks, economy exploits, AI pathing failures in emergent scenarios, or systemic gameplay balance issues. Those require human design validation and time. Faster world-building automation might even increase the volume of content that needs testing, creating a wider surface area for bugs if QA staffing does not scale proportionally. The engine does not manage that risk; management does.

Writing and design throughput remain human bottlenecks. UE5 does not generate quest dialogue, narrative coherence, or branching story logic. The Witcher franchise is built on writing density and consequential choice architecture. No renderer feature accelerates scriptwriting or narrative design iteration. If the project faces the same pressure to outscope its predecessors that defined Cyberpunk 2077, the engine will simply produce that overscoped content faster, not more coherently.

Finally, the engine swap does not rebuild trust. More than five years after Cyberpunk 2077’s troubled launch, CD Projekt Red recognizes it does not yet consider its redemption arc closed. Co-CEO Michał Nowakowski describes the launch as heartbreaking and acknowledges that severe bugs and crashes on PlayStation 4 and Xbox One damaged fan trust. Years of patches and the Phantom Liberty expansion improved the game, yet the studio acknowledges that some player trust was permanently lost. The studio has indicated longer-term plans to make fewer, larger releases, citing strong post-launch sentiment following Phantom Liberty as evidence that extended support windows can rehabilitate a title. That strategy, however, does not reduce the stakes for The Witcher 4’s day-one stability. No amount of Nanite optimization or RTX Mega Geometry integration repairs that relationship. The engine is invisible to players when the game works; it is only visible when it fails. Delivering a stable, complete product at launch is the only metric that matters for restoring credibility, and that outcome depends on execution, not middleware.

Engine Benefits and Lingering Risks

Verdict