DevelopingSkillsBlog

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

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

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

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

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

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

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

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

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

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

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

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 was where the project started to feel fully defined. Up to this point, I had collected a lot of desert, outpost, and sci-fi references, but this stage was about turning those influences into one clear concept. I wanted EREMUS to feel like a remote survey outpost on the edge of a hostile alien desert basin, where the foreground still supports sparse life while the wider landscape feels large, fractured, and exposed. Writing the concept helped me connect the environment idea with the procedural workflow I want to use in Houdini and Unreal.

Reference board used to shape the core concept for EREMUS, combining outpost design, desert scale, and alien biome elements.

How I Reached the Concept

The concept came from combining three directions that kept appearing in my references. The first was grounded desert sci-fi architecture, especially outposts that feel built for survival rather than spectacle. The second was large-scale desert landscape design, where cliffs, basins, and distant forms make the environment feel much bigger than the playable foreground. The third was the idea of procedural variation, where the scene is not treated as a single static build, but as an environment supported by reusable systems for terrain, structures, and scatter. Bringing those together helped me move from a moodboard to a project with a clear identity.

My Three Design Pillars

The first pillar, Functional Frontier Worldbuilding, means the outpost should feel practical and believable, with forms and props that suggest survival, repair, and survey work. The second, Layered Desert Scale, means the scene should balance a more detailed foreground with a vast, hostile basin beyond it, so the world feels larger than the playable area. The third, Procedural Systems with Artistic Control, reflects the production method itself: I want to use Houdini-based systems for variation and efficiency, while still keeping strong manual control over composition, focal points, and environmental storytelling.

Reflection

About the Project

Once I had the title and overall identity of EREMUS, the next step was to define what the project actually is and what I want the final outcome to be. This slide helped me move from a broad desert sci-fi idea into a more focused production direction. I wanted to make it clear that this is not an open-world project, but a single hero environment built through a Houdini-to-Unreal workflow with a strong emphasis on procedural worldbuilding and modular structure generation.

Studion - KK Design Fab listing - Scifi Desert Biom Early biome and vegetation references used to define the alien desert foreground.

KÉVIN ROUSSILLE MODULAR SCI-FI BASE - INDOOR OUTDOOR - MARS THEME References used to explore modular sci-fi base layouts and outpost planning.

Individual Artist - Kevin Jick Streets of Ta'ak Architectural references used to ground the outpost in a more believable desert settlement language.

Leartes Studios The Space Base in Red Planet Environment Outpost references used to define the intended scale, mood, and presentation quality of the final environment.

What This Slide Established

This slide helped me clarify two things. First, the project itself: a sci-fi desert environment centred on a remote survey outpost in a hostile alien landscape. Second, the intended outcome: one polished Unreal Engine hero scene supported by reusable Houdini tools for terrain, rock distribution, biome scatter, and outpost variation. Putting this together helped me separate the visual idea from the actual production goal.

Reflection

Project Title Development

For the opening slide of my pre-production document, I wanted the project to feel like more than just a technical environment exercise. I wanted it to have its own identity, world, and sense of presence. That is why I chose the name EREMUS for the project. The word carries meanings connected to desert, isolation, and loneliness in Latin, which felt very appropriate for the type of sci-fi environment I want to build. Since the project is centred on a remote alien desert outpost, I wanted the title to immediately communicate atmosphere as well as setting.

Cover slide for EREMUS: A Procedural Alien Desert Outpost Environment.

Why I Chose the Name EREMUS

The title was important because it helped me move the project away from sounding like a generic environment brief and closer to something that feels like an actual world location or organisation. “EREMUS” felt strong because it suggests remoteness, survival, and a harsher frontier condition, which aligns with the desert sci-fi tone I am aiming for. It also gave me a foundation for the in-world branding of the outpost, including the logo and organisational identity that could later appear on props, structures, signage, and other assets inside the environment.

Designing the Opening Slide

For the first slide, I wanted the visual to establish the mood of the project straight away. I used a wide desert scene with alien vegetation, distant rock formations, and a small outpost silhouette to suggest scale, isolation, and sparse habitation. The warm red-orange palette helped reinforce the harsh desert atmosphere, while the custom logo above the title made the project feel more like a believable sci-fi world rather than just a student presentation. I wanted the cover to communicate both the visual tone and the project’s procedural ambition in one image.

What This Slide Helped Me Clarify

Making this opening slide helped me define the project at a conceptual level before getting deeper into workflow, asset planning, and technical development. It made me think about the environment not only as a place to build, but as a world with its own identity and narrative context. That was useful because it immediately pushed the project toward stronger worldbuilding rather than just a collection of desert references.

Reflection

This slide was important because it gave the project a clearer voice from the start. Naming it EREMUS made the idea feel more focused and intentional, and it also gave me a stronger basis for later decisions around branding, mood, architecture, and environmental storytelling.

After building the Unreal material system, I moved into presenting the final sign styles inside a proper environment. For this, I used Downtown West, a free modular city environment released by Epic in collaboration with PurePolygons. The pack is designed as a flexible downtown streetscape with modular storefront facades, shops, signage, snack stands, and a large library of modular assets and materials, which made it a strong fit for testing my sign system in context.

What worked especially well about this environment is that it already has the kind of spaces where these signs would naturally appear: shopfronts, pavement edges, pedestrian routes, café fronts, and street corners. Because my tool produced both freestanding signs and wall-mounted / hanging signs, Downtown West gave me a believable setting for multiple styles instead of forcing all of them into one type of placement.

The wall-mounted hanging style worked well against the building facades because it reads clearly from a distance and feels appropriate for small business signage. The pipe support and suspended board fit naturally into the storefront rhythm of the scene.

The freestanding street sign also worked well in the Downtown West environment because the scene includes broad pavement space, curb edges, and pedestrian zones. That made it easy to imagine this type of sign being used as temporary or moveable commercial signage outside cafés or small retail spaces.

The A-frame style felt especially suitable near entrances and seating areas. It reads as a more everyday sidewalk sign, which fits the downtown setting better than a more isolated environment would.

The framed hanging version also benefited from being placed close to the shopfront architecture. Since Downtown West is built around modular storefront pieces and street-facing commercial layouts, it gave me a useful way to judge whether the more decorative or stylised sign structures still felt believable in a semi-realistic city scene

Overall, this stage was useful because it shifted the project from asset generation into context testing. Up to this point I had mostly evaluated the signs in isolation. Placing them into Downtown West helped me judge scale, readability, material response, and how each style behaved in an actual street environment. Since the pack is intended for building a busy downtown center with modular flexibility, it was a good match for a signage system that is also based on variation and reuse.

What I found most useful here was seeing how different sign types serve different roles once placed in scene. Some styles worked better as storefront identity pieces, while others felt more suited to pavement advertising or temporary street placement. That made the tool feel less like a set of isolated variations and more like a usable collection of signage assets for a small urban environment.

After stabilising the procedural tool in Houdini, I spent the next stage working more inside Unreal Engine. At this point the main goal was not to change the geometry again, but to make the asset system more usable through materials.

The most important part of this stage was building a master material setup and then creating material instances for the different surface types coming from Houdini.

Moving from Test Materials to a Reusable Material System

Earlier, I had already tested simple materials and Megascans textures on the generated signboards. Those tests were useful for checking whether the UVs and material slots were working, but they were still quite rough.

This time I wanted a cleaner system that could be reused across all the sign styles. To do that, I created a master signage material in Unreal and then built instances from it for different parts such as:

metal

wood

board surfaces

text elements

This made the setup much easier to manage. Instead of rebuilding materials separately for each sign, I could control most of the look through instances.

Creating Material Instances for Different Surfaces

Once the master material was in place, I created separate material instances for the different surface types.

For the metal parts, I adjusted roughness, normal strength, metallic values, and added surface imperfections so that the result felt closer to galvanised or painted metal.

or the wood elements, I built a separate instance using wood textures and adjusted the colour and roughness values so the signs could feel more like painted or treated timber rather than raw placeholders.

This was a useful stage because it moved the project closer to an actual asset workflow. The signs were no longer only procedural geometry — they were starting to behave like proper game assets with reusable material controls.

Using UV2 for the Text System

Another important part of this stage was the text integration, which comes from the earlier tutorial pipeline.

Instead of keeping the store name and slogan as heavy 3D geometry inside the final asset, the text was baked and then mapped through a second UV set (UV2) on the board surface. This meant the main UVs could still handle the board material, while the secondary UV set was used for the text data.

In Unreal, I incorporated this into the material so the board could show:

the base board texture

the overlaid text

additional control for text colour and visibility

This was a much more efficient approach than carrying full text geometry into the engine, and it made the asset more practical for real-time use.

Testing the Text Material in Unreal

Once the board material was connected properly, I tested the text integration inside the Unreal material instances.

This stage helped confirm that the UV2 workflow was doing what it was supposed to do: the board could keep its own material treatment while the text remained readable and separate in the shader.

I also tested lighter board variations to see how the text behaved against different surface colours and material settings.

This was important because readability changes quite a lot depending on the material contrast, especially for signage.

Reflection

This stage was less about geometry generation and more about turning the procedural output into a more complete engine-ready asset system.

Building the master material and the material instances made the workflow much more organised, while the UV2 text setup kept the signage practical for Unreal. Instead of relying on heavy text geometry, the board could now carry readable text through the shader itself.