DevelopingSkillsBlog

[artsclevervivekdevelopingskills]

Texturing Terrain in Houdini COPs: Placing Materials with Masks, Not a Brush

I textured an entire desert, a lava field and an icy mountain without once picking up a brush. Not a single pixel was hand-painted. Every colour landed where it did because a mask told it to, and each mask was computed from the terrain's own shape. That was the moment texturing stopped feeling like painting and started feeling like giving instructions.

This is the texturing strand of EREMUS. In the previous post I formed the three Terrain Handbook biomes, but forming them only gave me grey geology. This post is how that geology gets its colour, and the surprising part is how little of it is manual. Following Nikola Damjanov's COPs texturing chapters I textured all three biomes the same way, and again the most useful lesson was not any single look. It was building one colouring machine and pointing it at three different worlds.

Texturing without a brush

A heightfield in Houdini carries far more than height. Every erosion pass I ran in the last post quietly wrote extra layers alongside it: where water flowed, where cavities sit in shadow, where debris settled, how sharply each edge curves. Those layers are masks, red selections painted across the terrain by the simulation rather than by me. On top of them sits one node, heightfield maskbyfeature, that can invent a fresh mask from the terrain's own features, by slope, by height, by curvature, by which direction a face points, by ambient occlusion. So before I choose a single colour I already hold a stack of selections that know where the water ran and where the peaks catch the light. To hand-paint over that would be to throw it all away.

It is just Photoshop layers

To turn those masks into colour I move the terrain into COPs, Houdini's image context. One node, SOP Import, carries every heightfield layer across as a 4K image plane. From there the workhorse is the composite node, and the moment it clicked was realising it is exactly a Photoshop layer stack: a foreground colour, a background, and a mask deciding where the foreground shows through. The blend mode is the entire vocabulary. Over to place a colour, screen to lighten an edge, multiply to sink an occluded pocket, subtract for a little grain. I stack a dozen of these, each one adding a single material exactly where one mask says it belongs, and a quickshade node previews the result live on the terrain as I tune it.

The same stack, three biomes

The graph is nearly identical for all three biomes: import the layers, build a base colour from a ramp, run a long chain of composites, then preview. What changes is the palette, which mask drives which material, and one biome-specific mask each. That is the whole trick, and it is why one method makes three worlds.

The desert is the reference build and the most layered. A warm brown ramp sets the base, then debris lifts the settled sand to a paler beige, curvature paints white highlights onto the ridge edges and black into the crevices, ambient occlusion sinks a deep red into the shadowed pockets, and a fine noise pass, masked to the flats so it never touches the peaks, adds a grain that also feeds render-time detail. It reads as layered, wind-worked sand, and none of it was drawn.

The lava world keeps the exact same chain and only swaps the palette hotter and adds one mask at the front. I isolate the flow and water layers, rename them both to lava, and blend them with a composite set to minimum, which pools the mask into the river banks where lava would collect while keeping some erosion striation. When I sampled the base colours from a reference I deliberately picked the stones, not the lava, because the glow itself is added later in the shader. Ambient occlusion then reddens the banks and curvature brightens the rocky edges. Same machine, opposite temperature.

The icy mountains swap in snow logic. A slope mask drives near-white snow across most of the surface, then a height band built from a spline ramp lets me dirty the snow at the base with a multiply while leaving the peaks pristine. A flow-direction mask adds a pale ice-blue that reads like ice running down the slopes, and debris dirties the snow in patches. As with the lava, the softest part of the snow is not painted in COPs at all; the mask decides where, and the shader does the rest.

Why masks instead of a brush

The reason to work this way is not speed, it is that the erosion already knew everything. Flow, occlusion, debris and curvature are, as Damjanov puts it, a very nice set of masks we got for free from the simulation. They already know where water ran and where edges sit, so letting them place the materials keeps the whole thing procedural: change the terrain and the texture re-derives itself, with no repainting. It also stays resolution-independent, because a mask is a rule, not a grid of pixels. The blend-mode choices are simply intent written down: lighten here, darken there, vary gently over there.

It clicked slowly, over a dozen layers, when I stopped seeing the composite node as Houdini magic and recognised the Photoshop layer stack I already knew, until I trusted the masks more than my own eye.

Where it fought back

Building three of these back to back, the friction was rarely the big idea and almost always the plumbing. Twice a layer came out wrong because a composite was set to the wrong blend mode, and a reddish-yellow mess turned correct the instant I set it back to multiply. More than once a composite did nothing at all until I renamed a plane so both inputs shared a name, the kind of invisible rule you only learn by hitting it. And a stylised contour-line pass threw an intermittent error even the tutorial's author could not fully explain, worked around by copying a single channel into a fresh alpha plane. A lot of terrain texturing turned out to be quietly babysitting blend modes and foreground weights rather than any grand technique.

Mine was chasing a wrong blend mode far too long before spotting a single dropdown set to the wrong thing

What I carried into EREMUS

EREMUS is a desert, so the dusty texture is my working template, and the parts I kept are specific. The mask-driven base means the outpost's ground can be re-textured the moment I reshape the terrain around it, without repainting anything. The habit of reading the erosion layers as ready-made selections is now simply how I think about colouring any heightfield. And the biggest shift is the quietest: a texture is not a picture I paint, it is a set of decisions about where each material belongs.

I am trying to read the erosion masks before I make any colour choices, because that keeps the material placement tied to the heightfield rather than to a painted guess. Once those masks have done the first pass of deciding where things belong, the colour becomes a layer stack I can keep tuning, instead of a flat image I would have to remake every time the terrain changes.

This is the texturing groundwork for the terrain strand. The formation post shows how these three biomes were shaped in the first place, and the next post packages the EREMUS terrain into a tunable, tiling HDA, so this whole forming-and-texturing chain becomes one reusable generator.

If you are reading this as part of my Major Study, this post is the texturing learning strand: I textured all three Terrain Handbook biomes with the same mask-driven COP method to understand how procedural materials are placed, before texturing my own EREMUS ground, and set it down in the order I actually learned it.

[artsclevervivekdevelopingskills]

Terrain Formation in Houdini: What the Terrain Handbook Taught Me Across Biomes

The same erosion node built a desert ridge and a river of lava. All I changed was which kind of wear I let it simulate. That was the moment terrain stopped being scenery to me and became a system, and it happened while I was working through the Terrain Handbook to understand how EREMUS's ground should be made.

This is the terrain-formation strand of EREMUS. Before I could build my own desert basin as a procedural generator, I needed to understand how terrain actually forms in Houdini, not just which buttons to press. So I followed Nikola Damjanov's Terrain Handbook and built all three of its biomes myself, a dusty desert, a fiery lava world, and an icy mountain range. The most useful thing was not any single one of them. It was building the same small set of tools three times over and watching them produce three completely different worlds.

What a heightfield actually is

A heightfield in Houdini is not a mesh. It is a two-dimensional volume: a flat grid where the only thing you can push and pull is height. Every heightfield carries two layers that travel together, a height layer and a mask layer, and almost every terrain node reads both, height on the left input, mask on the right. The mask is just a red selection painted across the terrain that tells a node where it is allowed to act.

Once I saw it that way, the long list of nodes stopped being intimidating. Everything is doing one of five jobs: adding height (noise and pattern), shuffling height that already exists (distort), reshaping it (remap and terrace), simulating a physical process on it (erode and slump), or selecting a region to protect or target (mask by feature). You stack those, work at a low resolution while you find the shapes, and only up-res at the very end when the look is settled.

The same base, three different worlds

Every one of the three biomes starts from the exact same heightfield, the same size and the same spacing. What makes one read as sand and another as lava is not the starting grid. It is which physical process I chose to foreground, and how I made the very first shapes.

The desert is the most art-directed of the three. It does not start from noise at all, it starts from a hand-drawn curve. I drew the ridge lines I wanted on the ground plane, wrapped them into geometry, and projected that down onto the height as the skeleton of the terrain. From there it is noise and erosion to rough it up, but the defining move comes last: a flow field is computed and a slump pass lets sand settle down the slopes and gather in the crevices on its own. The desert is a story of deposition, material drifting and piling where gravity takes it.

The lava world throws the drawing away and starts from pure noise, several folded Perlin layers combined so that hills rise with channels running between them. Then it does something clever with erosion. Instead of one wear pass I split the two kinds apart: thermal erosion, the crumbling of slopes, builds the hills, while a masked water pass running only in the lowest parts carves the sharp channels the lava flows through. Debris is deliberately switched off so those channels stay crisp, and there is no slump at all, because letting material settle would fill in the very rivers the erosion worked to cut. The lava world is a story of directed erosion, two processes aimed at two different jobs.

The icy mountains start a third way again, from built geometry. I scattered pyramids across the grid and projected them up into peaks, with smaller upside-down pyramids cut in as holes to break them apart. Then two features do the heavy lifting. Big, strong terraces carve the strata you see in real mountains, and after the erosion passes the slump runs not once but twice, so snow appears to build up in the flats and shelves while rock still pokes through the steepest faces. The icy world is a story of layering and buildup, strata cut in, then snow deposited on top.

Why the differences matter

Set side by side, the lesson is simple, and it reframed how I think about terrain. The base is identical every time. Biome identity comes almost entirely from which process I let dominate: deposition for the desert, directed erosion for the lava, strata and buildup for the ice. Even the starting method carries intent. I hand-drew the desert because I wanted to art-direct where the ridges went, I started the lava from noise because I wanted chaos, and I built the mountains from geometry because I wanted deliberate, placed peaks.

Honestly it clicked in more than one place. The first was watching the same erosion node build a desert ridge and a lava channel just by turning the water off. The masks did the rest: once I saw terrain as height plus a red selection layer, the nodes stopped being mysterious. And the slump node was where it stopped feeling abstract altogether, watching sand settle into the crevices on its own.

Where it fought back

Building three biomes is not the same as them forming smoothly, and a few walls came up again and again. The first is patience. Erosion is a simulation, so every time I changed a number I waited for it to cook, and at high resolution that wait got long. The habit the course drills, and the one I have taken on, is to work at a low resolution while you find the shapes and up-res only at the end. It also runs erosion far too hard on purpose, then dials it back by blending the eroded result over the original, which turns a commitment into a control dial.

The second wall is a real limit of the format. A heightfield cannot hold an overhang, because every point on the grid has exactly one height. When the lava biome needed carved canyon walls, I had to leave heightfields entirely, convert the terrain to polygons, push the shape sideways, rebuild it through a VDB, and project it back, and running that at full resolution is heavy enough to hang the machine if you are not careful. That was a useful reminder that procedural terrain is a set of trade-offs, not a magic button, and that knowing when to step outside the heightfield is part of the skill.

Building the three back to back, the erosion cook times became the real tax, because a full pass meant waiting again every time I nudged a value, so working low-res first stopped feeling like a useful tip and became survival. The more honest wall was learning to read the terrain properly, because telling a real erosion channel from plain noise took several passes before my eye adjusted. The masks caught me out first too, as I kept feeding height into the mask input and wondering why nothing changed.

What I carried into EREMUS

EREMUS is a desert, so of the three biomes the dusty one is my closest template, and the parts I took from it are specific. The art-directed start, drawing the ridge lines rather than hoping noise lands them, suits a world with an outpost whose terrain has to be shaped around it. The slump pass gives the sand its settled, drifted look almost for free. And the ordering the whole course teaches, big shapes first, then detail, then erosion, then resolution last, is now simply how I build any heightfield.

The more important thing I took is not a biome at all, it is the way of seeing. Terrain is a base shape plus a chosen process, height plus mask, worked low and resolved late. Building all three is what let me build the EREMUS terrain in the previous post with some idea of why each node was there, instead of copying a chain and hoping it held together.

The lava biome's split erosion is the technique I think about most, even though EREMUS has no lava, because it taught me erosion is directable and not just destructive For now the desert approach is enough, and I would rather go deep on one biome than spread thin across three

This is the formation groundwork for the terrain strand. The introduction post lays out why EREMUS is procedural at all, and the build post shows the actual network this understanding produced. Next in the series I go from forming the terrain to packaging it, turning the EREMUS heightfield into a tunable, tiling HDA I can reuse.

If you are reading this as part of my Major Study, this post is the learning strand for the terrain: I rebuilt all three of the Terrain Handbook's biomes to understand how terrain forms before building my own, set down in the order I actually learned it.

[artsclevervivekdevelopingskills]

Why I Spent Part of My Major Study Building a Tutor Instead of My Outpost

I want to be straight about how this part of the semester actually went, because the honest version is more useful for a development blog than a tidy one. This post is about a decision that took me away from building the EREMUS outpost for a while, and why I think it was the right technical-artist call to make.

The problem I kept hitting

Most of what I do (Houdini, Unreal, Substance) I learn from tutorials. And I kept running into the same wall: on a single watch of a tutorial I would retain only a fraction of it. I would rewatch, scrub back, and lose the thread of why a node was there. A video cannot do what a teacher does: it cannot check my work, it cannot take a doubt, and it cannot adapt when I get something wrong. Meanwhile the industry is moving quickly: AI is now part of real production pipelines, and the pressure to skill up fast is real.

I would finish a two-hour Houdini tutorial and realise I could not rebuild half of it without scrubbing back through the video: the steps were in my head, the reasons were not. The pattern was always the same: watch, follow along, feel like I understood it, then hit a blank the moment I tried it on my own scene a week later. It hit hardest on a procedural tutorial where one node's setting changed everything downstream, and the video never paused long enough for me to understand why.

Treating it as a pipeline problem

Before games, I spent two years as a full-stack software engineer. So when I hit a recurring problem, my instinct is not to endure it. I treat it as a pipeline problem and build a tool for it. That is exactly what I did here. The result is an AI tutoring system that turns any DCC tutorial into an actual tutor. It breaks a tutorial into a module-by-module lesson plan, then, while I work live in Houdini or Unreal, it reads my real scene through an automation bridge at each checkpoint and tells me whether I have done the step correctly, answers my doubts grounded in the official documentation, and flags where I have deviated.

The first time it caught me building a node in the wrong order and said so before I had stacked ten more steps on the mistake, I realised it was doing what a teacher does, not what a video does. I asked it why a heightfield mask was not affecting my terrain, and it answered from the actual node documentation instead of leaving me to guess. That was the moment it stopped being a toy. At one checkpoint it read my live Houdini scene and told me my HDA was missing an exposed parameter the tutorial relied on, something I would never have caught on a single watch.

Why this is not a detour away from EREMUS

Crucially, I built and tested it on EREMUS's own skill stack, the exact heightfield, scattering and Houdini-to-Unreal tutorials this project depends on, including the Terrain Handbook and the procedural desert workflow. So it is not a detour away from EREMUS; it is the thing that teaches me EREMUS faster, and with verification instead of guesswork.

The honest evaluation

It took more of the semester than I budgeted for. That is on me, and it is the reason I have had to reduce the scope of the artefact, a decision I am documenting separately as project management. But the learning outcome is real: I now learn these tools with feedback rather than by guessing, and I can point to exactly where I was right and where I was wrong.

Was it worth it? For the artefact, it cost me time I cannot get back. For everything after this project, I think it was. I came out able to learn these tools with feedback instead of guesswork, and that compounds. Also it also expose to what i want to be in this field , "A Technical Artist" from my perspective i resolve many of my real-life problem regarding my course or learning and came up with a technical solution for them.

Where this sits in the field

This is not a niche idea. It is a known problem with recent evidence behind it.

Benjamin Bloom's classic 2-sigma finding (1984) showed that one-to-one tutoring makes students perform about two standard deviations better than standard classroom teaching. The catch has always been that human tutoring does not scale.

A 2025 randomised controlled trial by Kestin et al., published in Scientific Reports, found that students using a well-designed AI tutor achieved over double the median learning gains of in-class active learning, in less time.

And the industry context supports the direction: the GDC 2026 developer survey reports that roughly half of game studios now use AI in development, and 2026 trend reports name the "AI Workflow Specialist" as an emerging role.

Positioning myself

So the thing I built sits exactly on that line, scaling the one form of teaching we know works, aimed at the specific DCC tools I need for game environment art. Positioning myself there, between the craft and the pipeline, is the technical-artist direction I want to move in, and it is the same software-engineer instinct that got me into this field, now pointed at learning art faster.

Sources to cite in Harvard style in the planning folder's references:

Bloom, B.S. (1984). The 2 Sigma Problem. Educational Researcher, 13(6), 4-16.

Kestin, G. et al. (2025). AI tutoring outperforms in-class active learning: an RCT. Scientific Reports.

GDC 2026 developer survey / BCG 2026 Global Gaming Report (AI-adoption figures).

[artsclevervivekdevelopingskills]

In the last post I set the approach for EREMUS's terrain: build it procedurally in Houdini as a reusable, tiling system rather than a hand-sculpted Unreal scene, by combining what three tutorials each do best. This post is the first build, the actual Houdini network that turns that decision into terrain, from the first macro shapes through to a packaged HDA.

Starting with the macro shapes

I started from a HeightField and a distorted ramp heightfield_pattern. A ramp gives me parallel ridges, and turning on Distort curls them into the wind-blown sand lines I was after. I then stacked a few pattern copies with the layer mode set to add, big shapes first, then medium shapes, so the landform carries several scales of structure instead of one flat noise field. Building that macro silhouette before adding any detail was the single discipline the Terrain Handbook drove home across every biome, and it is what stopped the terrain looking like generic procedural noise.

The first version was too uniform, every ridge the same height, which read as noise and not landform. Stacking a second, larger pattern copy on top is what finally broke that up. Getting the number of stacked scales right was the fiddly part: one pattern looked flat, three looked busy; two, big then medium, was the balance.

Adding detail and structure

On top of the macro shapes I layered heightfield_noise, heightfield_slump, and a heightfield_resample pass. The noise and slump give the finer sand structure and settle the slopes so they read as real, gravity-affected material rather than a displacement pattern, and the resample keeps the resolution consistent for everything that comes after it.

Blending the dunes and driving the masks

I used heightfield_layer nodes to blend the dune field into the base, then drove the material breakup with masks rather than by hand. heightfield_maskbyfeature on height, slope and occlusion generates the masks that feed three material layers, sand, rock and worn, into a heightfield_quickshade. Masking off features like peaks, exposed slopes and cavities, instead of painting materials manually, is what keeps the whole thing art-directable: when I change the terrain, the masks follow it automatically. This masking-and-texturing approach is the part the Terrain Handbook goes deepest on, across its dusty, fiery and icy biomes.

Packaging it as a reusable HDA

The entire network is wrapped into a custom HDA, /obj/geo1/desert_terrain, with the parameters I actually tweak exposed at the top level. This covers Modules 1 to 5 of my terrain plan. This is where the procedural desert workflow shaped the decision: the world was always meant to be tiled and streamed into Unreal through Houdini Engine, so the terrain has to be a reusable generator that can also carry the scattering and PDG tiling later, not one hero mesh I can only build once.

I exposed the dune direction and scale, the noise and slump amounts, and the three mask thresholds (sand, rock, worn), the handful of controls I actually reach for when art-directing, so I can retune a tile without opening the network.

Evaluating the process

THE ITERATION WALL: "The slowest part was not any single node; it was iteration speed. Once the resolution was up and the slump and mask passes were stacked, every tweak meant waiting on a recook, so 'try an idea' became a minute-plus round trip, and that quietly shaped how boldly I experimented. Next time I would lock the shapes at low resolution and only crank it for the final look." MASKS LOOKING UNIFORM: "What caught me out is that art-directable masks are not automatically good-looking masks. My first maskbyfeature setup split sand, rock and worn cleanly by height and slope, and it read as three flat bands, exactly the uniform look I was trying to avoid. Breaking it up with occlusion and a little noise in the mask, instead of pure height thresholds, was the difference between 'procedural' and 'believable'."

Where this goes next

That is the first terrain, end to end, the macro shape, the detail and erosion, the feature-mask texturing, and the HDA that packages it all so it can be tuned and reused. The next posts take it further along the pipeline: texturing the terrain in COPs with feature masks instead of hand-painting, scattering the outpost floor across it, and getting it into Unreal through PDG tiling and Houdini Engine.

[artsclevervivekdevelopingskills]

EREMUS is an alien desert basin, a hostile, sun-bleached world with an outpost dug into it, and it is the environment I am building for my Major Study. Before any of that outpost exists, though, there is the ground it stands on. A desert is mostly terrain, and how I choose to make that terrain decides everything after it: whether EREMUS becomes a whole world I can keep growing, or just one nice-looking location. So the project starts here, with a single question: how do I want to build the terrain?

Why the terrain comes first

The terrain is the stage everything else stands on. The outpost, the props, the scattering of rock and debris, all of it has to sit on the ground and read as one place. Get the terrain wrong and nothing on top of it looks right; build it as something I can regenerate and re-shape, and the whole world stays open to change instead of freezing after the first pass. That is why I am treating the terrain as the first real decision of EREMUS, not a background detail to rush past.

The choice: a procedural system, not a hand-built scene

I have built a desert before, the other way round, entirely inside Unreal, sculpting the landscape by hand and placing every effect in the engine. It looked the part, but it was one fixed location: nothing about it could be regenerated or re-art-directed once it was made. For EREMUS I want the opposite. I want a terrain I can tune, tile, and stream into Unreal as a world of many pieces rather than a single hero mesh. So the decision is to build the terrain procedurally in Houdini, as a generator I can re-run, not a sculpture I can only make once, and bring it into Unreal from there.

Coming from software, a system I can re-run always beats an asset I can only make once, that instinct is exactly why I reached for Houdini here. I have hand-built environments before and watched them turn into dead ends the moment I needed to change something, and I did not want EREMUS to be another one. The outpost design will keep shifting as I go, and only a procedural terrain lets it shift with me instead of forcing a rebuild.

Three tutorials, none complete on its own

No single tutorial covers the whole path from an idea to a streamed Unreal world, so I am combining three, each strong exactly where the others are weak.

The first is the Terrain Handbook course, the only pure-Houdini terrain training I have, and the one that taught me most about how terrain actually forms and gets textured. It walks through several biomes, a dusty desert, a fiery one and an icy one, so I could watch the same heightfield tools produce completely different landforms and understand why. What it deliberately never does is leave Houdini.

The second is a procedural desert environment tutorial. It is lighter on the terrain sculpting itself, but it is built around exactly the part EREMUS needs: turning the terrain into a reusable HDA, scattering rock and debris across it, tiling it with PDG, and streaming it into Unreal through Houdini Engine. That scattering-and-outpost focus lines up directly with a world where the terrain is a stage for a desert outpost, not the whole show.

The third is not a Houdini tutorial at all: it is the earlier desert I built inside Unreal, following UnrealityBites' UE5 Desert Landscape and Effects, with the Landmass system for dunes, Megascans sand, and in-engine fog and dust. That one taught me the Unreal end: what the terrain eventually has to feed into, and what the final scene needs to look like.

The plan that came out of it

Put together, the three give a clear route. Use the Terrain Handbook to understand how the terrain is formed and textured; use the procedural desert workflow to turn that terrain into a tiling HDA that reaches Unreal; and use my earlier in-engine desert as the target for what it all has to produce. That synthesis is how I work on everything: research the options, compare what each is good at, then combine them into one workflow. Here it becomes the end-to-end Houdini-to-Unreal terrain plan for EREMUS.

The next post starts building it for real: the actual Houdini network, from the first macro shapes to a packaged, reusable HDA. From there the series follows the pipeline, texturing the terrain in COPs, scattering the outpost floor, getting it into Unreal through PDG and Houdini Engine, and a look back at that first all-in-Unreal desert set against this procedural system.

If you are reading this as part of my Major Study, this is the approach for the terrain strand: the reasoning first, then the build, documented in the order I actually worked through it.

[artsclevervivekdevelopingskills]

Finalising EREMUS — Outpost Branding and Production Planning

Closing the Pre-Production Document

For the last part of the pre-production document, I wanted to end on two things that make the project feel complete: identity and planning. The first was the branding of the outpost itself through the EREMUS logo. The second was the production timeline, shown through a Gantt chart that maps the project from pre-production refinement into terrain tests, modular asset development, look-dev, and final scene assembly. Since a Gantt chart is essentially a visual schedule that maps activities against time, it felt like the right format to close the document with a clearer production roadmap.

Outpost Branding — The EREMUS Logo

Final logo concept developed for EREMUS, the organisation behind the outpost.

The logo was designed as the emblem of the organisation responsible for establishing and maintaining the desert outpost. The name EREMUS also helped strengthen that worldbuilding direction. Public Latin and etymology references define eremus in relation to desert, wilderness, solitude, or deserted places, which matched the tone I wanted for the project: remote, exposed, and isolated.

Visually, the logo combines a circular celestial form with a four-point star, suggesting surveying, navigation, and long-range communication. The larger radiating form reads both as a desert sun and as an energy flare, which helped connect the emblem directly to the hostile landscape of the world. I wanted it to feel functional rather than decorative, so that it could sit naturally on walls, crates, tanks, signage, and equipment as part of the outpost’s visual identity.

Production Planning — Gantt Chart

Gantt chart planning slide Project timeline mapping the development of EREMUS from May to August.

The Gantt chart was my way of turning the research and reference-heavy side of the document into an actual production plan. I mapped the workflow across May to August, starting with pre-production refinement, workflow planning, and reference consolidation, then moving into terrain composition thumbnails, Houdini heightfield tests, Unreal landscape setup, outpost blockout, modular architecture, support assets, look-dev, scene assembly, and final presentation prep. Since Gantt charts are used to organise tasks on a timeline and show overlaps, dependencies, and duration, it was a useful format for visualising how the project should progress over time.

What These Final Slides Helped Me Clarify

Putting these two slides at the end of the document made the whole project feel more grounded. The logo gave the outpost a clearer identity inside the world, while the Gantt chart made the project feel less like an abstract idea and more like something that could be built step by step. Together, they helped connect the creative side of EREMUS with the production side.

Reflection

This felt like a good way to close the pre-production document. The branding slide reminded me that the environment needs a believable in-world identity, while the Gantt chart reminded me that good ideas only become useful when they are organised into a realistic plan. Ending on these two slides made the project feel both more imaginative and more manageable.

[artsclevervivekdevelopingskills]

Workflow Inspiration for EREMUS — Composition and Lighting Lessons from UNSC Outpost

Using a Night Scene Breakdown as a Presentation Workflow Reference

For this part of the pre-production document, I wanted to include a workflow reference that was less about environment type and more about presentation discipline. Stephen Falk’s UNSC Outpost breakdown was useful because it treats composition and lighting as decisions that need to be planned early, not just polished at the end. What mattered to me was not the fact that it is a night scene, but the way the project is built around thumbnails, focal hierarchy, value control, and purpose-driven design. That makes it surprisingly relevant to EREMUS, even though my own environment is a desert outpost rather than a Halo-inspired forest scene.

Final Beauty Shot of the Outpost Final scene image used as the main benchmark for how lighting, focal hierarchy, and composition are resolved in the finished environment.

Thumbnail / Planning Sketches Early planning sketches from the article, used to show how composition was explored through thumbnails before detailed production. Falk explains that he made rough thumbnails and landscape sketches to establish composition before moving forward.

Blockout / Building Design Image Reference used to study how the structure becomes stronger once its purpose is clearly defined. In the article, Falk says that once he decided the base was a temporary battlefield outpost, the functional details became much easier to design.

Annotated Composition / Lighting Useful example of how focal point, leading lines, and lighting work together to guide the eye through the scene. Falk explicitly frames lighting around focal point, contrast, full value range, palette, movement, and rule of thirds.

What I Took from This Workflow

The biggest takeaway for me was composition first. Falk explains that one of the weaknesses in an earlier project was the lack of contrast, strong focal point, leading lines, sense of scale, and physically correct lighting, so this time he spent much more time planning composition through thumbnails before production began. That feels very relevant to EREMUS, because I also want to make sure the outpost reads clearly inside a larger landscape rather than relying on detail alone.

The second lesson was purpose-driven detail. In the modelling section, Falk says he had been guilty in the past of filling a blockout with meaningless detail, so here he defined the actual function of the building first. That approach is useful for me because EREMUS also needs to feel like a believable survey-relay outpost, where forms, props, and extensions are connected to use rather than decoration.

The final lesson was lighting as composition control. Falk describes lighting as one of the most pivotal parts of environment art and says he kept in mind focal point, contrast, full value range, palette, movement, and the rule of thirds while building the scene. He also explains how color contrast was used deliberately, keeping most of the scene in muted blues while reserving orange for the garage focal point. Even though my project uses desert sunlight instead of moonlight, that way of thinking about exposure and visual hierarchy is directly useful for how I want to present EREMUS

Reflection

This reference was valuable because it gave me a stronger workflow for presentation. I am not using it for its exact look, but for its method: start with thumbnails, define the function of the structure, and use lighting to strengthen composition instead of treating it as a final cosmetic layer. That is exactly the kind of discipline I want to carry into the final presentation of EREMUS.

[artsclevervivekdevelopingskills]

Workflow Inspiration for EREMUS — Learning from Grand Space Opera

Using Grand Space Opera as a Workflow Reference

At this stage of the pre-production document, I wanted to include at least one environment breakdown that was useful not just visually, but structurally. Grand Space Opera stood out because it presents the environment as a clear production process rather than only a final beauty render. What I found most useful was the way the project is broken into landscape generation, nature, and man-made objects, which feels very close to how I want to structure EREMUS: terrain systems first, optional biome support second, and hard-surface outpost assets as the main built layer.

Final Beauty Shot from Grand Space Opera Final environment image used as the overall workflow benchmark for quality and structure.

Blockout Screenshot Blockout reference showing how composition, focus points, and scene planning were established early.

Houdini Terrain/HDA Overview Terrain workflow reference used to study how the environment is treated as a controllable system rather than a single sculpt

Landscape Layers / Generation Breakdown Supporting reference used to understand how the environment is built in separate production layers.

What I Understand from This Workflow

The strongest lesson for me was the importance of starting with blockout. In the article, Karabardin explains that blockout was used to determine foreground, background, focus points, guiding lines, and an early pass for lighting before the scene moved into detailed production. That was useful for EREMUS because it reinforced the idea that I should lock the scene boundary and composition before committing too heavily to assets or procedural tools

The second lesson was how the terrain is treated as a system. The article explains that the landscape was built in Houdini through two HDAs, with structured inputs such as terrain, preserved area, cliffs, rivers, and lakes, before being brought into Unreal as a layered landscape. That is very close to the kind of thinking I want in EREMUS, where the terrain should be controllable and iterative rather than just a sculpted backdrop.

The final takeaway was the layered production logic. The scene was not built as one giant pass. Instead, landscape, foliage, and hard-surface content were developed as separate but connected stages. Even though EREMUS will be much less foliage-heavy, that breakdown still feels useful because it gives me a cleaner way to organise the project into terrain, optional biome, and outpost systems.

Reflection

This reference was valuable because it gave me a workflow model rather than just another visual target. I am not using Grand Space Opera for its exact look, but for its production logic: blockout first, terrain as a system, and a layered approach to building the final environment.

[artsclevervivekdevelopingskills]

Testing the Look-Development Workflow for EREMUS

Lookdev Study Workflow

After setting Dune: Awakening as my mood and lighting benchmark, the next step was to think about how I could actually study and rebuild some of those visual qualities inside Unreal. For this slide, I wanted to define a workflow rather than just a moodboard. The official Arrakis development talk was useful for understanding how Funcom framed the desert world in terms of scale, atmosphere, and visual identity, while the UE5.4 tech-demo material helped me see how that cinematic desert presentation was being shown in-engine. On the practical side, the Bad Decisions Studio Dune remake playlist became a useful reconstruction reference because it turns those kinds of shots into hands-on Unreal exercises

Dune: Awakening Dev Talk / “How We Built Arrakis” Reference-analysis source used to study how Arrakis is framed through environmental scale, haze, and restrained composition. Funcom’s own developer update around the art of Arrakis explicitly discusses environment principles, landmarks, tools, and the worldbuilding approach behind the desert setting.

Dune: Awakening UE5.4 Tech Demo Technical benchmark used to observe how cinematic desert lighting and landscape presentation are carried into Unreal-based rendering. Search coverage identifies this material as a Dune: Awakening UE5.4 tech demo tied to the game’s next-gen visual presentation

Bad Decisions Studio Dune Remake Playlist Unreal reconstruction reference used to turn visual analysis into practical tests. The playlist presents a multi-part UE5 tutorial series focused on remaking Dune-inspired shots, and associated posts from the studio describe it as a workflow for recreating cinematic lighting, camera work, particles, and smoke-based atmosphere in Unreal.

What This Workflow Helped Me Clarify

This slide was useful because it gave me a method for approaching look-development instead of treating it like guesswork. I started to separate the process into three parts: first, studying the official references to understand what makes the desert world feel so large and atmospheric; second, using the UE5.4 presentation as a benchmark for technical presentation and rendering quality; and third, using the Bad Decisions tutorials as a way to test similar ideas in practice inside Unreal. That made the mood target feel much more actionable.

Reflection

This part of the document helped me connect reference study to production. Instead of saying that I want EREMUS to “look like Dune,” I could start thinking more clearly about what I am actually trying to learn: how scale is framed, how haze and lighting control depth, and how those ideas can be rebuilt through my own Unreal look-development tests. Using the references this way feels much more grounded and much more useful for the project.

[artsclevervivekdevelopingskills]

Setting the Mood and Lighting Target for EREMUS

Mood & Lighting Target

For this part of the pre-production document, I wanted to define the visual atmosphere I am aiming for rather than just collect more environment references. I used Dune: Awakening as a look-development benchmark because Funcom’s own development material frames Arrakis around environmental scale, atmosphere, landmarks, and the overall challenge of bringing the desert world to life. What I found most useful was not any one screenshot, but the way the game presents the desert as vast, exposed, and hostile while still making built spaces feel grounded and intentional.

Dune: Awakening Environment Mood Board Mood and lighting references used to study scale, atmospheric depth, and restrained sci-fi presence across the desert landscape.

The Art and Making of Dune: Awakening Supporting reference used to understand the wider art direction and environmental development behind Funcom’s version of Arrakis. The official artbook is described as a 224-page volume with concept art and interviews, covering locations from Hagga Rift to the Hand of Khidr.

What I Took from This Reference

The strongest takeaway for me was the lighting logic. I want EREMUS to use warm low-angle sunlight, dusty atmospheric depth, strong horizon separation, and a restrained amount of sci-fi architecture within a much larger desert space. That balance is important because it keeps the world feeling severe and exposed, while still allowing the outpost to read as a purposeful built presence. The official artbook announcement also describes the book as showing the art and vision that laid the foundation for the Arrakis seen in the game, which made it useful as a supporting design reference rather than just a promotional object.

Why the Book Was Useful

I also wanted this slide to show that I was not only looking at final screenshots, but also at the design process behind them. Available descriptions of The Art and Making of Dune: Awakening emphasise that it includes concept sketches, renders, and developer interviews, while preview coverage specifically mentions environmental locations such as Hagga Rift and the Hand of Khidr. That was useful for me because it reinforced the idea that the desert mood of the game is built through clear environmental art direction and not only through technical polish.

Reflection

This slide helped me move from general desert inspiration into a more precise look-development target. It gave me a clearer idea of how I want EREMUS to feel visually: broad, dry, exposed, and atmospheric, with the outpost reading as a small but intentional presence inside a much larger hostile world.

[artsclevervivekdevelopingskills]

Keeping Foliage Optional in EREMUS — Biome References and Workflow Research

Optional Biome Layer

At this point in the pre-production document, I wanted to address foliage without letting it take over the project. Since EREMUS is mainly focused on terrain, modular outpost design, and procedural environment workflows, I decided to treat vegetation as a supporting biome layer rather than a core production target. These two slides helped me define both the visual direction for sparse alien plant life and the optional workflows I could study if I later decide to extend the biome further.

Foliage Reference (Optional Biome Layer)

Sci-Fi Desert Biome / KK Design Main biome reference used to study sparse alien vegetation, environmental layering, and foreground ecology. The Fab pack was especially useful because it presents a large 16 km² environment with 161 assets, PCG/blueprint systems, landscape layers, grass support, and foliage materials with wind interaction, which made it a strong benchmark for how a desert biome can be organised at production scale.

Star Citizen: Hurston Vegetation Reference used to study how vegetation can remain sparse while still giving a large world more ecological identity.

Star Citizen: Hurston Vegetation More stylised and curated alien plant forms as a way of adding biome identity without overcrowding the scene.

This first slide was about deciding what role vegetation should play in the environment. I did not want EREMUS to become just sand and buildings, but I also knew that fully custom foliage production would add a lot of extra scope. These references helped me think about a middle ground: sparse, selective plant life that supports the foreground and gives the world more identity, while still keeping the desert open and exposed. That decision also made it easier to justify using sourced biome assets if needed rather than treating foliage as a main authored system.

Foliage Workflow Reference

Project Titan Ivy Tool Reference used to study how ivy could be generated procedurally. SideFX describes the Ivy Tool as a system that uses an input shape to grow ivy, generate branches and leaves, simulate falling branches, and package the result for Unreal.

Project Titan Shrub Tool Reference used to think about smaller procedural plant assets for foreground biome dressing.

Project Titan Tree Pivot Painter Reference used to understand tree workflows that support better in-engine motion and interaction, useful if vegetation ever needs more believable movement.

Procedural Bonsai Tree Reference used to study smaller-scale custom tree generation and branch structure inside Houdini.

Unreal Procedural Foliage Tutorial Reference used to consider Unreal-side foliage placement as a lighter alternative if vegetation remains a supporting biome layer rather than a main custom workflow.

The second slide was more about possibility than commitment. I wanted to show that I had still researched how foliage could be approached procedurally if the project ever needed it, but that I was consciously treating it as optional. The SideFX references were useful because they showed how plant forms such as ivy, shrubs, and trees could be built procedurally and integrated into an engine workflow. At the same time, the Unreal foliage tutorial was useful as a reminder that a lighter in-engine placement workflow might be more realistic if vegetation only remains a secondary layer.

What These Slides Helped Me Clarify

Together, these slides helped me make an important scope decision. I now see foliage as something that supports the biome and foreground readability of EREMUS, but not something that should dominate the project. That feels much more manageable and much more in line with the actual priorities of the environment.

Reflection

This part of the document was useful because it let me acknowledge the importance of vegetation without pretending it would be a major deliverable. It gave me a clearer boundary between what is central to the project and what remains an optional extension.

[artsclevervivekdevelopingskills]

Extending the Procedural Workflow of EREMUS — Support Tools, Props, and Structural Systems

Procedural Support Tools and Reusable Prop Systems

At this stage of the pre-production document, I wanted to push the project beyond terrain and architecture and think about the smaller systems that could make the outpost feel assembled, functional, and more production-aware. These slides came from the tutorial links I had gathered earlier while planning the project workflow. Instead of treating support props as isolated one-off models, I started looking at how cables, platforms, fences, stairs, doors, panels, crates, and utility objects could be approached as reusable procedural systems.

Procedural Support Tools

Pipe Generator Reference Reference used to think about utility routing, repeatable service connections, and how pipe systems can help make the outpost feel mechanically linked.

Platform Tool / Project Titan Reference used to study how basic shapes can generate modular platforms and then be extended with instanced details. SideFX describes the Platform Tool as a system that uses basic shapes to generate platforms, then adds instanced details around them, as part of the Project Titan Unreal environment workflow.

Cable Tool / Project Titan Reference used to study fast cable dressing and environmental connection logic. SideFX explains that the Cable Tool creates a collection of cables with varying thickness, simulates them so they drape naturally, and wraps the setup into a Houdini Digital Asset for use in Unreal.

This first group of references helped me think about the outpost as a connected system rather than a set of disconnected props. The Project Titan tools were especially useful because they show how local structural details such as platforms and cables can be generated procedurally and then used directly in an Unreal environment. That was important for EREMUS because I want the smaller support elements to reinforce the idea of a working site, not just decorate the scene.

Procedural Prop & Structure Tools

Project Titan Fence Tool Reference used to study perimeter control, barriers, and modular edge systems. SideFX describes the Fence Tool as a system that uses input curves inside the Unreal editor and combines generated geometry with instances, including newly created corner geometry that works at different angles.

The second group of references helped me broaden the procedural side of the project. What I found useful here was not the idea of building every tool myself, but the logic behind them. These examples show that procedural workflows do not have to stop at terrain or layout. Smaller asset families such as fences, stairs, crates, panels, terminals, and doors can also be treated as adjustable systems. For EREMUS, that helped me think about a more flexible production strategy where repeatable outpost details could support faster iteration and stronger visual consistency.

What These Slides Helped Me Clarify

These slides were useful because they made the procedural side of the project feel more layered. Earlier, I had been focusing mostly on terrain and modular architecture. This research showed me that smaller support systems and prop families can also contribute to the workflow in a meaningful way. It gave me a better understanding of which assets might eventually benefit from procedural thinking, and which ones are better kept as supporting references rather than direct commitments.

Reflection

This part of the document helped me connect the environment to a wider production mindset. The more I worked through these references, the clearer it became that EREMUS is not only about building one desert scene, but about exploring how a small outpost environment can be supported by reusable systems at multiple scales.

[artsclevervivekdevelopingskills]

Planning the Secondary Asset Language of EREMUS — Utility, Dressing, and Structural Support

Asset Families for the Outpost

Once the main outpost direction was clearer, I needed to think about the smaller supporting assets that would make the environment feel inhabited and believable. For these slides, I split the asset research into two groups. The first focused on utility and dressing assets such as crates, cylindrical tech, lights, cables, and pipes. The second focused on support and structural detail, including panels, antennas, towers, stairs, and shed-like add-ons. Breaking the references up this way helped me think about the outpost as a working place rather than just a collection of buildings.

Utility & Dressing

Boxes and Crates Reference Board Storage and transport references used to define repeatable utility props around the outpost.

Cylindrical Tech Reference Board Cylindrical machinery and tank references used to shape generators, filters, and utility forms.

Cylindrical Tech Reference Board Lighting fixture references used to think about smaller reusable light assets for entrances, pathways, and work zones.

Cable and Pipe Reference Board Cable and pipe references used to connect structures, props, and utility systems into one believable operational network

This first group of assets helped me focus on the secondary language of the outpost. Crates, tanks, cables, and smaller lights are the kinds of details that make a place feel functional and used. They also help break up repetition and create small storytelling moments around larger structures. I found the cable and utility references especially useful because they reinforce the idea that the outpost is part of a wider operational system rather than a few disconnected buildings

Support & Structural Detail

Sci-Fi Panels Reference Board Panel references used to study modular surface breakup and facade variation.

Signal Antennas and Towers Reference Board Communication tower and antenna references used to reinforce the survey-relay identity of the outpost.

Shed / Canopy Reference Board Shade, canopy, and lightweight shelter references used to extend the outpost with more grounded add-on structures.

Stairs Reference Board Stair and access references used to define traversal, elevation changes, and modular support structures.

The second group was more about structural support assets that extend the outpost beyond its main building forms. Panels help break up larger surfaces, antennas and towers reinforce the communication role of the site, and stairs and canopies make the environment feel more layered and physically usable. These references were important because they helped me think about how the outpost could grow through attachments and support pieces rather than only through large hero modules.

What These Slides Helped Me Clarify

These slides helped me separate the asset plan into more manageable layers. Instead of treating every reference as the same type of prop, I started to see the outpost in terms of asset families: utility dressing, structural support, communication hardware, and traversal pieces. That made the production side feel more realistic because it gave me a clearer idea of what could be repeated, what could become procedural later, and what should mainly support the larger architecture.

Reflection

This stage was useful because it made the outpost feel more like a real working site. The bigger architectural forms define the identity of EREMUS, but these smaller asset families are what make the place feel assembled, occupied, and operational.

[artsclevervivekdevelopingskills]

Studying Procedural Architecture Workflows for EREMUS

Procedural Architecture Workflows

After defining the architectural style and modular logic of the outpost, the next step was to look at how that logic could be supported through procedural workflows. For this slide, I collected references that focus on modular building generation, scalable architectural variation, and kit-based assembly inside Houdini and Unreal. The goal was not to copy these workflows exactly, but to understand how they could inform a smaller outpost system for EREMUS.

CG Crucible / Architecture for Games in UE Reference used to study modular architecture thinking and how kit logic can support environment assembly.

Simon Verstraete / Generating Sci-Fi Buildings Reference used to explore scalable sci-fi building workflows and controlled facade variation.

Andrew Guan / Procedural Building Generator Reference used to understand generator-based workflows for architectural variation and reusable structure logic.

Viktors Anfimovs / Procedural Building from Modules Workflow reference used to study modular building generation in Houdini, including instancing, variation, and Unreal transfer.

Why I Included These References

This slide was important because it helped me think beyond static modelling. Since EREMUS is meant to use a Houdini-to-Unreal workflow, I needed references that showed how architectural systems can be generated, adjusted, and reused rather than built entirely by hand. These examples were useful because they all approach buildings as modular structures made from repeatable parts, which fits the kind of outpost kit I want to develop.

How This Connects to My Project

What I took from these workflows was not the idea of building a full city generator, but the logic behind procedural structure systems. For EREMUS, that means thinking in terms of core modules, repeatable forms, controlled variation, and reusable sci-fi detail. This helped me define a more realistic direction for the project, where proceduralism supports the outpost kit instead of becoming the entire project by itself.

Reflection

This stage helped me connect the architectural design of the outpost with the production method behind it. It made the project feel more structured, and it gave me a clearer idea of how procedural workflows could support modular planning without making the scope too large

[artsclevervivekdevelopingskills]

Developing the Architectural Direction of EREMUS — Desert Forms and Modular Outpost Systems

Architectural References

When I was planning these slides, I realized the architectural side of EREMUS needed to answer two separate questions. The first was about visual language: what should the outpost feel like in terms of form, material, and settlement logic? The second was about production: how could that architecture be broken into modular parts instead of becoming one large unique build? Because of that, I split the research into two parts: traditional desert forms plus sci-fi adaptation and modular outpost systems.

Traditional Desert Forms + Sci-Fi Adaptation

Tech Repair Outpost / Megan Hill

Reference used to study grounded desert sci-fi architecture, weathered materials, and local outpost storytelling. Megan Hill’s Tech Repair Outpost is especially useful because it focuses on art direction, technical workflow, materials, and storytelling within a desert sci-fi environment.

Desert Village / Ryan Vinson

Reference used to study makeshift silhouettes, clustered settlement logic, and a less polished frontier feeling. Ryan Vinson describes it as “a group of villagers in makeshift homes in the desert,” created while practicing workflows in Blender to achieve more interesting silhouettes and design language.

Streets of Ta’ak / Kevin Jick

Reference used to explore dense desert street language and inhabited sci-fi settlement forms.

AI-Generated Concept Taking Inspiration from Megan's TECH OUTPOST

AI-generated concept for modularity and variation.

This part of the research was about getting the overall architectural tone right. I did not want the outpost to feel too sleek or overly futuristic. Instead, I wanted it to feel low-rise, weathered, and adapted to the desert. These references helped me focus on rounded silhouettes, compact building footprints, sun-worn plaster-like surfaces, and utility attachments that make the structures feel practical and inhabited rather than decorative.

Modular Outpost Systems

Modular Sci-Fi Base / Mars Theme

Reference used to study how a sci-fi base can be broken into repeatable units and larger layout systems. The Fab listing describes it as a high-poly sci-fi kitbash intended to let the user “build your own sci-fi base,” which made it useful for thinking about modular planning rather than one-off modelling.

KitBash3D Outpost

Reference used to study settlement-scale modularity and how larger outpost arrangements can be assembled from reusable building parts

Once I had a clearer visual direction, I needed to think about how the outpost could actually be built in production terms. This is where the modular references became useful. They helped me move away from the idea of designing one completely unique hero building and instead think in terms of core modules, support structures, utility expansions, and layout flexibility. That logic fits much better with the Houdini-to-Unreal workflow I want to use, because it supports variation, reuse, and controlled iteration.

What These Slides Helped Me Clarify

Together, these two slides helped me define both the look and the build strategy of the outpost. The first slide established the architectural identity: grounded desert forms mixed with practical sci-fi additions. The second slide clarified the system behind it: the outpost should be developed as a modular kit that can support different footprints, support units, and extensions without needing every structure to be rebuilt from scratch.

Reflection

This stage was important because it stopped the architecture from becoming too vague. It gave me a clearer set of design rules for what the outpost should feel like visually, while also helping me think more realistically about modular planning and procedural iteration later in production.

[artsclevervivekdevelopingskills]

Planning the Terrain Pipeline for EREMUS — From Houdini Landscape Systems to Unreal Environment Building

Developing the Terrain and Environment Workflow

After defining the visual direction of EREMUS, I needed to move into the technical side of how the desert environment could actually be built. At this stage, I focused on two connected areas: first, how to approach terrain and rock generation through Houdini-based workflows, and second, how that work could be refined and presented inside Unreal Engine. Bringing these references together helped me think about the environment as a pipeline rather than just a set of final images.

Part 1 — Landscape and Rock Workflow References

Procedural Desert by Simon Verstraete Reference used to study large-scale procedural desert building, including terrain generation, scatter, and man-made prop integration.

Working with Landscapes in Unreal by Viktors Anfimovs Workflow reference focused on Houdini heightfields, Unreal landscape layers, and terrain integration between Houdini and Unreal Engine.

Advanced Asset Creation / Rebelway Procedural asset workflow reference used to think about reusable systems rather than isolated environment assets.

Procedural Rock Generation by Steven Skidmore Rock workflow reference used to understand shaping, strata creation, low-poly generation, UVs, and texturing for reusable desert rock assets.

The first half of this research focused on how the terrain itself could be generated and controlled. These references were useful because they approached the desert not just as a sculpted backdrop, but as a system built through heightfields, scatter logic, and reusable rock workflows. They also helped me understand how to split the environment into controllable parts such as landscape generation, rock formation, and secondary terrain variation.

Part 2 — Unreal Environment Build References

UE5: Desert Landscape & Effects / UnrealityBites Unreal workflow reference used to study desert terrain setup, dust effects, sand movement, and atmospheric presentation.

Landscape Material / Unreal Sensei Reference used to understand landscape materials, blending, and flexible ground setup inside UE5.

Mesh Painting Material / Hoj Dee Studio Workflow reference for mesh painting and material breakup to reduce repetition and improve local surface detail.

Helldivers 2 Environment / Polygonflow Dash Reference used to study faster scene assembly, environment dressing, composition, and final scene polish in Unreal Engine.

Once the terrain is built, the next challenge is how it gets refined inside Unreal. These references helped me think about the Unreal side of the pipeline: landscape materials, surface blending, mesh painting, atmospheric effects, and final scene assembly. This was important because I do not want the project to stop at procedural generation in Houdini. I want the terrain to hold up visually inside Unreal as a believable environment with stronger composition, surface variation, and overall presentation quality.

What These Slides Helped Me Clarify

Together, these two slides helped me define the relationship between Houdini and Unreal in my workflow. Houdini makes more sense as the place for terrain generation, system building, and reusable landscape logic, while Unreal becomes the space where those results are integrated, refined, lit, and composed into a final scene. Thinking about the project this way made the pipeline feel much clearer and more realistic.

Reflection

This stage was useful because it shifted the project further away from reference collecting and closer to actual production planning. It gave me a more structured way to think about how the desert, rocks, materials, and final environment build should connect across both software workflows.

[artsclevervivekdevelopingskills]

Shaping the Environment Inspiration for EREMUS

Environment Inspiration

After defining the core concept for EREMUS, I needed to organise my environment references more clearly. Instead of treating them as one large moodboard, I broke them down into three things that felt most important for the project: terrain scale, settlement language, and biome identity. This helped me understand not just what looked good visually, but what each reference was actually contributing to the design direction of the outpost and its surrounding world.

Star Citizen: Daymar Large-scale desert reference used to study openness, horizon distance, and exposed terrain.

Dune: Awakening Desert landscape reference used to explore dramatic landforms, atmosphere, and hostile environmental scale.

Helldivers 2 Reference used to study rock silhouettes, harsher terrain rhythm, and exposed desert formations.

For terrain, I was drawn to references that made the world feel much larger than the playable foreground. Wide desert basins, cliff silhouettes, and distant horizon forms were important because I want EREMUS to feel isolated and exposed rather than crowded. These references helped me think about how the outpost should sit within a bigger hostile landscape.

Settlement Language

Star Wars: Tatooine Settlement reference used to study compact desert architecture and inhabited sci-fi space.

Kevin Jick: Streets of Ta’ak Reference used to explore weathered desert city forms and grounded sci-fi settlement density.

Star Citizen: Hurston Industrial settlement reference used to study functional structures and harsher man-made desert occupation.

For the built side of the environment, I wanted the outpost to feel functional rather than decorative. These references helped me think about how desert settlements can feel believable through low-rise structures, weathered materials, and practical layouts. Even though EREMUS is only a small outpost rather than a full settlement, these images helped define the larger world it belongs to.

Biome Identity

Sci-Fi Desert Biome Pack / KK Design Biome reference used to define sparse alien vegetation and foreground ecology.

The biome layer was important because I did not want the environment to become just sand and buildings. This reference helped me think about how selective alien vegetation could add more foreground interest and world identity without overwhelming the desert setting. It gave me a clearer idea of how sparse life might survive around the outpost.

Reflection

This slide helped me sort out the environment direction in a more useful way. Instead of collecting references randomly, I started understanding them as design tools. That made it much easier to define what I want to take forward into terrain building, architecture planning, and mood development for EREMUS.