On August 24 local time, Pearl Abyss revealed the creation process behind the open-world continent of Pywel in Crimson Desert at gamescom dev, a game developer conference held in Cologne, Germany. The session title was "Crimson Desert: How We Filled the Vast Continent of Pywel & Scaling Open World Creation with an In-House Engine".

While Pearl Abyss previously gave a lecture focused on the game design of Crimson Desert at CEDEC in Japan, its presentation at this gamescom dev focused on art.

The presentation was delivered in sequence by Pearl Abyss Art Level Division Head Geun-tae Ahn, along with Game Engine Graphics Division Heads Jinhwan Kim and Jinho Yoon. Ahn presented on the environmental art and world-building principles of the continent of Pywel, Kim covered the real-time rendering and world representation structure of the proprietary BlackSpace Engine, and Yoon detailed the terrain, procedural generation, and scene-level creation tools.

The session had 320 pre-registrants for a 150-seat capacity, completely filling the auditorium. The pre-registration list included Sony Interactive Entertainment CTO Luis Villegas, Capcom Deputy General Manager Kota Fukasawa, CD Projekt Red Senior Level Designer Miles Tost and Senior Technical Animator Julius Girbig, Guerrilla Games Senior Quest Designer Blake Rebouche, Sandbox Interactive Technical Director Jonathan Davis, Unknown Worlds Senior Game Designer Alexander Heath, and Nintendo Programmer Kentaro Nagasawa.

"Crimson Desert: Designing Playable Nature Instead of Replicating Nature"

Ahn oversaw the environmental art, world-building, and environmental level design for the continent of Pywel. He noted that the same questions recur whenever an open world is revealed: How was this vast space built, how many trees were planted, and how many assets were used? While acknowledging that these are all valid questions, Ahn explained that once production on Pywel began, the development team spent their time addressing a different set of questions: What should we show the player, how should this world feel, and what drives the player to move to the next location?

The first topic was nature. Early in development, the team operated under the premise that an environment closer to nature is better. However, once production began, they realized that realistic nature does not align with gameplay. Ahn cited a photograph of a real forest as an example: while it captures the light and depth forged over millions of years of trees competing for sunlight, transferring that untouched space directly into a game leaves players with no sense of where to go, what to look at, or where landmarks should be positioned.

He remarked that if a player were dropped in the middle of a forest and told to find a tower 500 meters away, they would spend 10 minutes struggling with tree branches before giving up. Real forests obstruct sightlines, cause disorientation, and obscure landmarks. Ahn summarized that the core issue was that nature was never designed for a player holding a controller—and that what needed fixing was not the trees, but the objectives.

The team shifted direction toward designing a playable nature in-game rather than reproducing real nature. They established four criteria: the player's gaze must be guided into the distance, landmarks must be discoverable, broad sightlines must be secured, and the space must support both traversal and combat.

Based on these criteria, the developers designed vegetation density rather than merely placing trees. Even within the same forest, they differentiated between standard woodland and deep forest, applying different densities depending on whether a zone served as a player's traversal path, a discovery point, or a combat area. Ahn stated that the goal was not a realistic forest, but a readable forest, and optimizations were directed accordingly.

The intended result becomes apparent when a player stands on a ridge looking past the tree line: they should be able to identify multiple distinct destinations at a glance without needing quest markers. The team intentionally placed plain, quiet forest stretches ahead of combat zones or high-event areas to create contrast. Ahn explained that if every part of a forest is interesting, paradoxically, nothing in it feels special.

The second topic was scale. The continent of Pywel was too vast to be built entirely by hand. Ahn stated that relying solely on manual placement was impossible for any team size or studio timeline. Indeed, regional quality varied significantly, final results depended heavily on individual artist skills, and repeating the same tasks caused revision costs to balloon.

The alternative chosen by the team was a sample-based production pipeline. First, they manually crafted small representative areas that embodied the desired density and readability. From these samples, they extracted rules—such as how vegetation is distributed along roads, how erosion presents on slopes, and how landmarks cluster around bodies of water. They then connected Houdini-based procedural generation to the production workflow, applying these rules across the entire continent.

Ahn emphasized the true purpose of automation: rather than pocketing the time saved, they reinvested it into variations between samples, overall visual quality, and dense environmental composition. As a result, improving the quality of a single sample automatically elevated the quality across the entire continent governed by the same rules. Ahn explained that the pipeline was built specifically to achieve this structure, noting that the fundamental shift in perspective was key. When the core question changes from "How do we fill more of the continent?" to "How do we create something worth replicating?", automation becomes a quality multiplier rather than a mere shortcut.

The third topic was turning the environment into gameplay content. The developers wanted the environment to be more than a static backdrop. The intended flow involves a player reaching a ridge, spotting something in the distance, heading toward it out of curiosity, and spotting another interest point before even arriving. Ahn noted that this repetition forms the core of open-world exploration—a chain reaction driven by curiosity, rather than quest markers or checklists.

Out of this emerged the principle: "If you can see it in the distance, you must actually be able to go there." The developers placed Pywel's landmarks directly within playable content rather than as background art, repeatedly verifying distant points by visually identifying them and walking to them. Ahn explained that after a few hours of play, players learn that distant objects are always reachable, earning their trust in the horizon. From that point on, players stop waiting for quest markers and begin reading the game's visual language.

He also discussed the criteria for effective landmarks. If a landmark stands out too aggressively, it feels detached from the world, like a postcard pasted over the landscape. Conversely, if it blends too seamlessly into nature, players miss it entirely, rendering the work wasted. The team put significant effort into striking a balance between the two.

Design was also separated by distance. A simple silhouette works well from far away, but feels barren to a player who approaches close up, instantly breaking the sense of scale. The developers designed most major landmarks twice: once based on how they read from 1 km away, and once based on how well they hold up from 10 meters away.

An element that proved more critical than expected was the skyline. Ahn explained that before a player can discern carved stonework or barrels atop a distant tower, they first perceive its silhouette against the sky. The team spent extensive time adjusting how terrain elevation, tree placement, and landmark silhouettes merged with the sky, repeatedly verifying them across various conditions—such as dawn, noon, and storms—and from multiple approaches. A landmark that only works from a single angle fails its purpose. Ahn noted that when the skyline clicks, players might not consciously notice it, but they immediately feel it is right—and that reaction was precisely what the developers aimed for.

Principles Refined from Failure: "Exploration Takes Priority Over Beauty"

Ahn shared three failure cases, noting that the team learned the most from their mistakes. First, areas that drew admiration from the entire team when shown as screenshots during review meetings crumbled during actual gameplay. Dense forests hid wildlife and scripted events, while lively details hand-placed over a week were obscured by foliage and lost on the player.

Second, overly complex terrain disrupted player movement. Unable to find comfortable paths, players got lost or snagged on obstacles—obstacles that had been placed simply because they looked good in screenshots.

Third, certain regions lacked density. While distant views matter, the critical benchmark remains eye-level player perspective; internal reviews pointed out that a drone camera flying high over the level does not represent what players actually see.

From these experiences, the team concluded that visual beauty and explorability are not the same thing. Ahn stated that while both values can coexist—and achieving both is the ultimate goal—when they conflict, explorability must take precedence. An open-world environment must not settle for being pleasant to look at; it must make players want to move through it.

At the close of his presentation, Ahn returned to the initial questions. Addressing how many trees were planted and how many assets were used, he admitted that while an almost absurd quantity was placed in Pywel, asset count was never the defining factor. A forest's success relies not on whether tree density per square meter is realistic, but on whether a player standing at its edge feels compelled to step inside.

He summarized that Pywel was filled not with assets, but with reasons to explore—adding that if players stand on a ridge in Pywel, gaze into the distance, and feel driven to keep walking, then the development team has achieved its goal.

"We Built a World That Operates as a Single Unified State"

Kim, an engine developer with 18 years of experience in game engine development and real-time rendering, oversaw the open-world rendering and large-scale world production support technology in the BlackSpace Engine used for Crimson Desert. He noted that BlackSpace Engine is not designed exclusively for Crimson Desert, but serves as a shared technical foundation for upcoming titles such as DokeV and PLAN 8, engineered to deliver a consistent world and gameplay experience across PS5, Xbox, PC, and Mac.

The engine's core objective was rendering large-scale worlds in real time. Kim explained that they wanted a continuous space extending seamlessly from right beneath the player's feet all the way to distant terrain and the horizon. This yielded three core requirements: space must remain uninterrupted from the horizon to the player; terrain, objects, and vegetation must feature representation methods matched to distance and importance; and visibility alongside scene complexity must stay within available frame budgets.

The world is equally dynamic. Changes in time, weather, and wind movement must propagate consistently across lighting, atmosphere, vegetation, and water, and player actions must generate immediate responses while these elements remain synchronized. BlackSpace Engine addresses this across three pillars: spatial rendering that bridges long and short distances, world-state representation that propagates time and weather changes, and interaction systems handling environment and player actions. Kim explained that these three pillars are not isolated functions, but share the exact same underlying data.

Kim highlighted that the correspondence between map distance and traversable space matters more than sheer geographic area. Although the player's location is just a single point on the global map, close-up gameplay areas and distant regions are visible simultaneously, requiring the engine to process both as a single continuous world.

The engine processes distance by dividing it into roughly 1 km, 3 km, and 10 km bands. Interactive objects and high-density details remain in the near field; terrain and structures occupy the mid-range; while forests, landmarks, and the sky reside in the far distance. Kim stated that the goal was not a logically simplified, barren landscape, but a view packed with enough content to stay convincing while remaining strictly within the performance and memory limits of target hardware.

To manage this scale, BlackSpace Engine divides the world into over 20,000 independent management units. A master structure orchestrates the entire world, toggling activation status and detail levels for each unit based on player position. Distinct content types—such as terrain, indoor spaces, quests, and triggers—are managed independently, allowing them to load or unload individually without affecting adjacent areas. Objects needed solely for events or gameplay are spawned at runtime.

Streaming pre-activates units required for the current viewpoint and anticipated near-future sightlines, while unloading areas rendered unnecessary based on visibility, distance, and direction of movement. Resource streaming is split into two tracks: texture streaming feeds the necessary mip levels, while mesh streaming delivers LODs for buildings, vegetation, and terrain. This means an active unit does not need to hold all assets at maximum quality. Asynchronous I/O, decompression, and preparation tasks execute without stalling frames, with requests handled by priority. Existing assets remain visible until replacement assets are ready, preventing visual pops across loading boundaries.

LOD consists of five levels, incrementally reducing geometry and material detail as distance increases. Beyond a certain range, objects transition into simplified proxies, retaining their silhouettes in distant views rather than disappearing. Kim explained that this phased transition maintains an unbroken connection from close-up playable space to distant terrain. The same methodology applies to objects, vegetation, and terrain, with the runtime selecting the representation method based on distance, screen-space size, and importance.

The core of optimization lies in division of labor between CPU and GPU. The GPU handles highly parallel tasks, including visibility culling, distance-based detail selection, and processing large-scale objects and vegetation. CPU updates and systems are divided into multiple jobs, with a scheduler resolving dependencies and ordering execution before linking up with GPU tasks.

This architecture applies directly to vegetation processing. Crimson Desert fills vast areas with varied flora and props, which would incur prohibitive costs if the CPU handled each element as an individual object. BlackSpace Engine utilizes a GPU-driven framework for visibility tests, distance-based representation selection, and rendering, populating expansive regions based on rules such as density, scale, slope, and exclusion zones. Developers then manually adjust specific points as needed—a compromise that maintains large-scale placement efficiency while safeguarding regional identity.

The team also determined that for distant vegetation, species identity and distribution matter more than individual tree mesh geometry. Developers prepared over 100 tree species, switching representations based on distance and viewing direction. Kim revealed that up to 500,000 units can be rendered in a single scene, maintaining forest density and distant ridges without fully rendering every tree into the far background.

Geometry alone cannot generate depth at such distances. BlackSpace Engine renders atmosphere and clouds using physics-based models. As sunlight passes through the atmosphere, scattering and attenuation accumulate along view rays, causing sky color, brightness, and contrast to dynamically react to sun position and viewing distance. Consequently, near and far spaces are delineated by the atmosphere itself rather than uniform fog. Clouds share these same lighting and atmospheric parameters, ensuring that long-range atmospheric perspective and cloud depth remain consistent across the entire world. Clouds are rendered across two distinct altitude layers, with varying heights conveying vertical depth and weather scale.

Dynamic global illumination combines hardware ray tracing with software ray marching to update lighting on the fly without precomputation. A software-based radiance cache distributed across the world stabilizes noise in the results, with coverage scalable via graphics settings. In addition, multi-light rendering handles numerous local light sources generated by the environment, combat, and visual effects. Light shapes, intensities, and directions can also be extracted directly from particle simulations, managing processing costs even as lighting setups shift.

Water spans from oceans stretching past the horizon to small ponds and flowing rivers. Because scale and behavior vary, systems are divided accordingly: oceans utilize wave profiles and swells, whereas bounded bodies of water react to dams, borders, and props. Crucially, all water bodies share uniform lighting, wind, and weather parameters to maintain environment-wide consistency. Shallow water near the player relies on real-time simulation, while distant water is driven by flow maps, wave height shifts, and signed distance field (SDF)-based collisions—allowing interaction and far-distance rendering to coexist without jarring visual seams.

Kim repeatedly emphasized the concept of a shared world-state. A single environmental change propagates simultaneously across lighting, atmosphere, terrain, vegetation, and water, synchronizing sightlines, surface responses, and environmental motion. At dawn, the distant landscape in a given location appears hazy; as the sun moves, shadows and atmospheric colors shift together into dusk. Localized stars and fog derive from that same time state. When rain falls, precipitation, background reflections, lighting, and distant visibility respond in tandem with regional weather conditions; when snow falls, precipitation, sky brightness, atmospheric density, and background clarity interconnect into a single unified environment.

Wind is governed by a fluid simulation field. After calculating localized air motion, intensity, and flow, results are shared across water, vegetation, cloth, fog, dust, particles, and surrounding objects. This structure ensures elements in the same space react to a single unified condition rather than playing disjointed individual animations. Kim explained that wind is not applied uniformly across the entire world; direction and velocity vary by location and vegetation density. When a character moves, the simulation field updates, causing nearby grass and trees to react dynamically to that force.

Player actions are also handled through a unified interaction framework rather than isolated implementations. By passing contact position, force direction, and action state to vegetation, water, cloth, objects, and NPCs, each element generates real-time responses tailored to its physical properties. Vegetation produces three distinct reactions from the same input: temporary bending from contact forces, persistent states like cutting or breakage following an impact, and continuous contact with the player.

Kim demonstrated these features in sequence. As a character moves through, grass bends based on contact point and direction, then restores itself once they pass. When an attack connects, grass is sliced according to strike position and radius, transitioning into a distinct persistent state separate from temporary bending. Grabbing a tree bends both trunk and branches according to grip location and pull direction. During climbing, hand and body contact points update continuously, with the tree responding to every movement. Impact force and point of contact cause trees to sway or snap, with destruction persisting in the world. Kim concluded that vegetation is not a static backdrop, but an interactive gameplay element that responds dynamically to the player.

Summarizing the core design principles of BlackSpace Engine, he stated that the world must remain continuous; time, weather, lighting, water, and vegetation must be maintained as parts of a single shared state; and player actions must trigger immediate reactions without breaking that continuity.

"Standardized Production via Terrain, Procedural Generation, and Scene Levels"

Yoon developed the overall scene-level system and environmental rendering for BlackSpace Engine. He stated that his focus was on maintaining consistent scene quality across a vast open world while improving level production efficiency. His presentation covered the terrain system, procedural generation, and scene-level systems in sequence.

The terrain system had two primary goals: reducing quality variance across different developers, and establishing a workflow that allows terrain to be easily edited and managed.

Rendering relies on heightmaps and normal maps as base data. Adding mask levels and displacement maps generates mid-range and close-up geometry at runtime, adding extra detail to terrain near the player. Materials utilize region data stored in region maps. Each region dataset contains four material sets with textures, displacement, vegetation settings, and physics data. The engine queries current and adjacent region data, calculates weights using mask maps, and blends the two primary materials. This structure lets artists directly define regions and tailor material combinations for different environment types.

Terrain creation employs a layered stacking approach. Height layers define boundaries and raise or lower terrain; river layers carve out waterways; road layers flatten paths; while additional layers handle distinct terrain features. Stacking these layers yields the final terrain map. Because each layer handles a specific aspect of the landscape, individual edits can be made independently, and preserving original data makes subsequent modifications simple.

However, heightmaps face limitations when creating vertical cliffs or intricate overhangs. In such cases, the team uses dedicated meshes linked to the terrain. These meshes apply terrain material functions to their top surfaces for seamless blending with surrounding ground, while dynamically varying cliff patterns, colors, and surface attributes based on terrain region data. In Crimson Desert, multiple meshes were combined into reusable cliff presets to construct massive mountain ranges and bluffs. Yoon noted that this approach generated rich variations from a modest set of meshes and textures.

Creating terrain and filling the world are distinct challenges. The developers introduced procedural generation to minimize manual placement, placing an automated placement system at the core. This system operates across two scales: large-scale placement and small-scale placement.

Large-scale placement scatters medium-sized objects—such as small trees, bushes, grass, and rocks—over broad areas. It utilizes placement groups defined in terrain region data, with each group specifying which objects to spawn and how to distribute them. Because distribution is controlled via parameters such as density, scale, position, elevation, and slope, artists can create distinct environments per region simply by tweaking parameters.

Small-scale placement handles close-up details like moss, fallen leaves, vines, and pebbles. It similarly utilizes placement groups, but draws from screen-space buffers, allowing application to static mesh materials as well as terrain. Because both systems generate objects on the GPU at runtime, level data size is reduced and environmental management becomes easier.

For other procedural tasks, external tools such as Houdini and Blender were integrated into the production pipeline. The engine passes terrain or object data to external tools, which process it procedurally to generate assets before sending them back into the engine for production use. Yoon explained that this workflow automated asset creation and placement, enabling game content to be generated on demand whenever required.

BlackSpace Engine uses two types of levels for object management: sector levels and manual levels.

The majority of objects are managed by sector levels, which divide the world into a 256m grid and automatically assign objects based on their location and size. This design allows developers to focus on building the world rather than manually assigning individual objects to levels. However, loading a sector previously loaded out-of-view objects as well, driving up memory usage and rendering costs. To resolve this, the team introduced auto sub-levels, dividing each sector into sub-levels based on object position, size, and data type.

Manual levels are used for content requiring custom control. Yoon cited the floating islands in Crimson Desert as an example—complex areas that appear only under specific conditions. In such cases, level designers manually configure level hierarchies, streaming conditions, and loading ranges.

Distant levels utilize proxies instead of original assets to reduce rendering and memory overhead. Proxies merge multiple objects into optimized meshes, generated automatically during build processes. The challenge in an open world is that when levels change due to quests, events, or player actions, merged proxies struggle to reflect those changes. The team solved this by embedding original object information directly within proxy meshes. As a result, proxies reflect the current state of objects even from far away, preventing the world from appearing static.

Yoon noted that developing Crimson Desert with BlackSpace Engine required both a method to rapidly expand the world and an efficient process capable of handling ongoing changes during development. He explained that the systems presented serve as mechanisms to eliminate repetitive tasks, simplify world management, and empower diverse developers to maintain consistent quality across the world.