Building Real-Time Temple Environment In UE5 Inspired By Baldur's Gate 3

Introduction

Hi there, this is Mandar Warde. I'm a Material Artist at Caterpillar on the CAT Visual team. My primary focus is building and maintaining the materials library, which publishes to four different render targets and is used by several teams. Alongside that, I design our texturing pipelines, lighting, profiling, and I optimize projects.

My path here is less than obvious. I started out as an engineer, studying electronics engineering in Mumbai, and joined a startup as an intern. Over the next five years, I grew into a Senior Game Engineer and led a team of four. After shipping more than six AR, VR, and simulation products, I realized I wanted to express myself more, and that's when the art side started pulling me in.

I did a Master's in Game Science and Design at Northeastern University, Boston. While I was there, I worked at Ghostlab as a Technical Artist with a focus on shaders, working on training and simulation projects funded by the US Navy. Later, Northeastern offered me a role as a graduate lecturer, and I taught 3D Asset Creation for Games.

The biggest jump in my material work came from my mentor, Jonathan Benainous. He showed me how AAA Material Artists actually work in production. Before that, my materials looked good on their own, but there was no system behind them. Learning to build that system, and to read materials the way the industry does, is what led to Shar Temple.

The Shar Temple Project

Shar Temple was my second mentorship project with Jonathan at Vessel Forge. Our first project together was all about understanding the production pipeline: how studios actually use materials, and the context those materials live in. Once we wrapped that up, I realized I had a lot of skills I wanted to show in a full environment, like tileables, modularity, and trim sheets. At the same time, I happened to be playing Baldur's Gate 3.

In the Gauntlet of Shar, I could see a lot of great composition and design principles, and it felt like a space where I could really show those skills. Shar Temple is inspired by the Gauntlet of Shar from Baldur's Gate 3 by Larian Studios, but it's my own take on the space rather than a one-to-one recreation.

For this project, I set one goal: push my material art to its limits and go beyond what the concepts and reference images were showing me. I wanted it to feel like working in a production environment, so I set myself strict deadlines, especially on materials. The core idea was to build the whole space as a material system: a fairly small set of tileables, trims, and decals doing most of the work, with unique textures saved for the hero pieces.

The first step was planning. I usually spend a lot of time on planning, and this project was no exception. I pulled as much reference from the Gauntlet of Shar as I could and started breaking it into sections, marking which surfaces could be trims, which could be tileables, and which really needed to be unique.

A few things defined the material identity right away: purple stone everywhere, gold inlay running through the floors and the trims, big circular openings, and red overgrowth creeping over everything. From there, I planned my trim sheets and worked out every section the architecture would need, all before modeling anything.

Blockout & Modeling

By this point, every surface in the temple already had a job: trim, tileable, or unique.

Once I had my measurements, I jumped straight into Blender and started the blockout. I try to keep everything as close to real-world measurements as possible, mainly because it makes texel density mapping much easier later. Once the proportions felt right, I rebuilt the blockout as a modular kit, which included arches, columns, wall sections, and a set of reusable kitbashed pieces.

The kit was all mapped to one texel density. My baseline was a 2K texture covering a 200 × 200 cm grid, which works out to 1024 px/m, and I mapped the kit against that. Then I mapped the trim sheets onto the kit, all before anything went into Unreal. Once done, I assembled the space and did a very quick first material pass, just to see how everything read together.

It's not glamorous work. But it's what keeps everything from falling apart later.

For the architecture, I built the kit around the trims from day one. A handful of trim sheets ended up covering almost every arch, column, and frame in the temple, so when the trims were ready, they just slotted in.

For props, I sculpted three candle clusters and the skulls in ZBrush, then baked high-poly to low-poly in 3D Painter. Every candle in the entire scene goes back to those three meshes. Each one is under 500 tris, and they're instanced across the whole project. I didn't want to spend much mesh budget on the banners, so the base mesh you see in the breakdown is pretty much what's in the final scene, and the detail mainly lives in the textures.

The vegetation is one of the main storytelling pieces in the scene. The red vines are what tell you this place has been abandoned for a long time. I grew them with Polygonflow's Dash plug-in, which let me control where they spread and how dense they get, directly in the engine. The goal was for the growth to follow the architecture, climbing the columns and pooling in the corners, so it reads like something that grew there over time and not something that was sprayed on.

A few things saved me a lot of time:

• Sorting every surface into trims, tileables, and uniques up front;
• One texel density across the whole kit in the initial phase;
• Three candle meshes instanced across the entire scene;
• Dash for the vines, so I could grow and adjust them in the engine instead of placing them by hand;
• Keeping the banner meshes simple and putting the detail into the textures;
• A cloth simulation for the carpet instead of modeling the folds by hand;
• A fast first pass on every material, so I could read the whole scene early and correct things in later passes.

Retopology

Most of the environment was built with topology in mind from the very beginning, so I didn't have to do much retopology at all. The exception was anywhere I needed to show chipping. Those parts followed the traditional route: a high-poly sculpt in ZBrush, baked down to the low-poly in Substance 3D Painter.

The props followed a similar workflow. I sculpted the high polys in ZBrush, built the low polys from them using Decimation Master, then brought both into Substance 3D Painter and baked the extra detail down. The candles were made exactly this way.

Unwrapping was fairly straightforward, because the main goal was keeping texel density consistent. I unwrapped in Blender's UV editor and checked density with a checker texture on the kit pieces, using a texel density checker add-on for Blender. Nothing fancy.

The one place that needed special care was unwrapping the arches for the trim sheets. I made sure the arch UVs were straight with no stretching, and that every piece was oriented correctly, so the textures ran in the right direction and the normal maps didn't come out flipped or look wrong. Pieces that use trim sheets were unwrapped so their UV strips line up with the trim sections and read as seamless. The tileable surfaces kept a similar texel density, and I used triplanar projection in the shader for them, so they're effectively mapped to world scale.

Texturing

Twenty-eight procedural materials, all built in Substance 3D Designer, carry this entire environment. The hero props with unique textures, like the banners, doors, and candles, were textured in Substance 3D Painter. All the tileables are 2K, and the trims were planned around them. A few unique assets were sized to fit the space they cover, so texel density stays consistent across the whole scene. On the engine side, I kept it standard, with ORM-packed masks alongside base color and normal, so the focus stayed on the materials themselves.

I treated the materials like a production schedule, with three passes:

• First pass, one week. Early versions of all 28 materials, just enough to read the scene in the engine;
• Second pass, about three weeks. Detail, and a lot of learning. The tile cracking logic alone took one of those weeks;
• Third pass, about a week and a half. Polish and edits.

The whole scene, color-coded by how each surface was built, shows how the system works. Blue is unique textures. Pink is tileables, some with RGB masks. Green is trim sheets, edge decals, and atlases. Cyan is kitbashed pieces I reused. Most of the scene is pink and green: unique textures are saved for the hero pieces, and everything else comes from a fairly small set of reusable materials.

The Floor

If the floor doesn't hold up, nothing does. It's the hero surface, and in almost every shot it's the biggest thing on screen. It isn't one material, but several materials layered together. Starting at the top of the breakdown, there's the hex, then the sundial, followed by the trim sheet, and so on. Splitting it this way means I can change a layer without rebuilding the other types.

Hex Tiles & Tile Cracking Logic

Early on, I realized tiles don't crack the way I thought they did. Figuring out how they actually break was one of the most complicated parts of the whole project, and it's what makes these floors read as real.

When we think about tiles cracking, we usually picture the pieces popping straight up. That's not really what happens. The force on a tile usually comes in at an angle, so the pieces move in a tangential direction and end up layering on top of each other instead of lifting straight up. I sketched this out with arrows to make it more visible.

The tiles here were made of different materials (marble, limestone, and gold inlay), so the chipping varies, and the displacement changes a lot too. The pieces are all different sizes, so the forces acting on them are different, and they all act in different directions.

When a tile cracks, pieces also go missing. So I made sure some of those missing pieces show up scattered across the same surface. If you look closely, you can spot a few. That's my tracking logic: tracking the missing chips across three different materials. I even ended up studying soil erosion, so the ground underneath reads as something solid, and the tiles on top feel like thin tiles sitting on it.

In the graph, the material builds up in stages:

• Base shape. The easiest part to create;
• Tile cracking logic. How the pieces break and shift, as described above;
• Shape tracking. Tracking the pieces that are actually missing, rather than throwing random chips on top of the material;
• Material blend: gold and marble. The first blend, between the gold inlay and the marble;
• Material blend: limestone. Gold and marble, mixed with limestone;
• Dirt and grout. Driven by how each piece was displaced and how it moved;
• Surface imperfections. Scratches, cracks, and so on, based on where each piece sits. This is where I had to study erosion;
• Rock scatter. Small rocks for the high-frequency information that makes it believable;
• Roughness, edge wear, and variation. How the roughness follows the surface, and how I can tell a story through roughness and edge wear;
• Salt and pepper. AO and curvature touch-ups. At this point, it's an art direction step, making the surface readable for the player from a distance;
• PBR metallic validation. I check that my base color and metallic values stay in a physically valid range, so whoever lights the scene (in this case, me) can light it properly. Right now, this is the most critical step in my entire pipeline.

Each stage lives in its own section of the graph, so I can push the damage without touching the pattern, and the other way around.

Once I figured out the cracking logic the first time, it trickled down into a single node. Naturally, the surface combinations are different for every material, but the same logic carries through the rest of them.

Marble

The marble was one of the first materials where I really started paying attention to noise frequencies. It's a little ironic, because most of the materials I'd made before leaned on heavy normals or heavy displacement. With this one, I wanted the surface to be interesting without any crazy normal maps or displacement. It should still read and communicate what the surface is, without any fancy techniques.

That meant focusing on frequencies, and this is where Jonathan helped me understand them. I broke down the information I wanted the material to communicate into three frequencies, low, medium, and high, and built each one as its own layer. At the end comes the roughness variation and, as always, the PBR metallic validation.

Vertex Painting

Tileable materials repeat; that's the trade-off. Vertex painting is how I break them up. I painted two material types directly in the engine, checking the surface from different angles while I painted in the damage. This is also where the floor starts to tell a story: damage goes where people would have walked and where something fell.

Stone Trim

The stone trim carries most of the architecture. Every colored band in the placement overlay is one section of the trim sheet, mapped to the arch, column, or frame it sits on.

Cloth

The carpet is a completely different surface type, and the material is 100% Substance 3D Designer. It needed to read as woven and soft, with gold stitching, and still sit believably next to all that hard stone.

Leaf Decal

This one sits underneath the leaves falling from above, like a backdrop. It adds a bit of shadow so the ground underneath isn't directly exposed, which gives some lift to the leaves sitting on top. The leaves on the ground are covered in dirt and completely dead, with some rocks mixed in.

Unique Assets: Banners & Doors

The banners started from the base mesh. Then came the base materials and PCG masks, which I built with 3D Painter's line tools instead of drawing them by hand. The same line tools handled the edge stitches. After that came grunge and cloth folds for variation, weathering, and discoloration, and finally opacity masks to cut the tears into the cloth.

The doors got the same 3D Painter treatment in wood and metal, and the build-up above shows each step.

Scene Assembly

Once the kit was in Unreal, I assembled the space piece by piece and brought in a first pass of everything: the kit, the trims, and early versions of all the materials. Early on, I walked around the scene at player scale, just to check that everything was working before I committed to detail.

From there, I layered the detail on top: props first, then the vines and decals. Because every candle is an instance of one of three meshes, I could scatter them freely across the temple, and Dash let me grow the vines right over the assembled architecture. The floor damage was painted in by hand with the vertex painting setup from earlier.

Composition was the hardest part of this project for me. Coming from engineering, I was fairly new to it, so I had to learn it along the way. I had a lot of help from the Vessel Forge community. Shout-out to Penny Gaubatz, who helped me get the gist of how composition works. I also kept going back to my reference images, the game itself, and its concept art.

I leaned on leading lines, and I used the angle of the light hitting the door to pull the eye where I wanted it to go. I definitely didn't get it right on the first shot. It took a few tries before everything sat well in the frame.

The day and night shots needed different approaches. At night, I wanted more VFX and more light sources, so the materials had more to react to. The day scene was already bright, so I kept point lights to a minimum there. Add too many, and they start fighting each other for attention.

One weird quirk of mine: I listen to a lot of the game's music while I work. It helps me build the vibe in my head before I start putting a scene together.

Lighting & Rendering

A material that looks great in daylight can completely fall apart at night. This scene had to work in both, so I started testing lighting early, on purpose. Testing early meant every material decision after that point was made under real lighting, not on a sphere sitting in a void.

One of the first things those tests showed me was that I couldn't just use purple light everywhere. Instead, I mixed warm and cool light and let the purple come out of the mix. That mattered most in the night scene. The day scene was relatively straightforward.

For the day scene, a lot of my time went into understanding how god rays actually get created. Most of it came down to finding the right fog density and learning how the atmospheric fog and volumetrics work together. Too dense and the fog hides all the detail I'd worked on. Too light, and you lose the rays. It took me a couple of tries to land on a balance that looked right and communicated what I wanted.

For rendering, I used Movie Render Queue through Sequencer, exporting PNG sequences at 24 FPS for a cinematic feel. For post-production, I graded the day and night sequences in Lightroom for final touch-ups.

Conclusion

Six months, all of it after work. The project ran from February to August 2026. The mentorship itself ran for about two months, but the project kept going long after it. I built it alongside a full-time 40-hour week at Caterpillar, and I took about a month off in the middle of it. Roughly: reference, planning, and blockout ran from February into March, materials in March, the modular kit and trims in April, props in April, vines and decals in May, lighting and final renders in June, and then a final pass on lighting in August.

The biggest technical challenge was the tile cracking logic. Figuring out how tiles actually break, and then building that into a graph, took a full week on its own. The other challenge was that I was new to a lot of things on this project, so there was a real learning curve, and some stages were slower than they would be now. If I tackled something like this today, I could probably do it in half the time. That's really the point: rinse and repeat, and you get better every time.

The biggest lesson was planning. Every hour I spent on reference, trim planning, and texel density before modeling paid off later, because nothing had to be rebuilt once it reached the engine. The other lesson was to keep systems separate. Because each stage of a graph does one job, I could push one thing without breaking another.

My advice to beginning artists: plan before you build, and take breaks. Projects like this always run longer than you think. Finally, a huge thank you to Jonathan Benainous. It's one thing to be great at your work, and a completely different thing to be a great teacher, and Jonathan is both. He pushed me where I needed it most, including into things I'd been scared to try. And thank you to 80 Level for the opportunity to share this project.

Mandar Warde, Material Artist

Interview conducted by Emma Collins