[As of July 13th, 2026: this page is still under construction!]

My contributions

My contributions for this project includes the following:

• Establishing, communicating, and documenting UE5 Best Practices
• Performance profiling and investigation
• Supporting Data Validation with UE5 tech findings
• Developing and validating asset creation workflows
• Fluid and fog tech R&D
• Material creation
• Contributing towards project-wide tech decisions
• Project-wide rendering settings validation and implementation

Establishing, communicating, and documenting UE5 Best Practices

Unreal Engine 5 comes with a selection of tech and workflows that the team, myself included, weren’t very familiar with at the start of this project. Shortly after the launch of South of Midnight in April 2025, and driven by my own personal interest on the topics, I conducted preliminary research on UE5 tech such as Nanite and Lumen. Naturally, this interest progressed to me taking more ownership of these topics, and further developed into in-depth investigations that often included collaborating with core engine programmers to gain a deeper understanding of these systems.

For numerous core UE5 features, I conduct extensive research before distilling my notes down to concise documentation, which is then formatted in a clean and accessible manner. This documentation is then communicated to the team, primarily environment artists, through shared meetings between the environment art and tech art teams. With any new updates or engine upgrades, the documentation is updated accordingly, and artists are notified of the changes with a Slack message summarizing the new additions/adjustments.

Documentation

My goal regarding documentation is to be able to communicate information efficiently, and in a way that is digestible by the intended audience. In regards to the documentation I wrote regarding best practices, I kept the following ideas in mind:

• Only provide as much detail than necessary; don’t lean too far into technical jargon that don’t help communicate the point
• Piggyback off of terminology and concepts that the target audience of the document is already familiar with
• Consider the cleanliness of the page’s layout; don’t make the page infinitely long, and organize information in a logical manner
• Provide definitions for terms that may not already be familiar to the target audience
  • The best practice pages are intended to be reviewed not only by the artists, but also by engine programmers. Thus, the understanding of various technical terminology varies based on the audience. In these cases, definitions for such terminology are provided in a collapsible glossary with the aim to provide additional context
• Provide brief explanations behind each recommended practice
  • The reasoning behind each recommended practice are tied to workflows and examples that artists are already familiar with
  • The intention is to make each recommended practice feel less “arbitrary”

Performance profiling and investigation

One of the learnings from South of Midnight‘s development is to look at the project’s performance much earlier on in the development cycle.

Some of the goals of looking into performance in pre-production are to:

• Analyze how existing visual target maps were performing in relation to Nanite/Lumen
• Observe how artist-proposed content creation workflows perform with Nanite/Lumen’s recommended workflows and constraints
• Validate recommended best practices provided by Epic’s documentation
• Validate and observe how various fluid simulation tech function with Nanite-enabled meshes
• Validate and propose “safe” ranges regarding various Nanite and Lumen parameters
• Validate project-wide rendering settings
• Dive deeper into what’s happening under the hood regarding Epic’s recommended best practices

The general workflow I take when conducting performance investigations are as follows:

1. Set out a clear goal for the performance investigation; what is the purpose of the test?
2. Set up a test environment. This can vary based on what’s being tested: it can be an existing level, or a gym to test a specific construction method
3. Create shelves for each test
4. Copy camera locations of places to take GPU captures
5. Kick off Preflight builds, one per shelf, on TeamCity
6. Install the builds onto an XBOX GDK through Hermes
7. Open each build on the GDK, and snap the camera to the copied camera location(s). Make sure necessary parameters are set in the dev kit prior to opening the build to ensure certain info can be captured (e.g. Material draw events to reveal material names)
8. For each camera location, take a GPU capture using PIX
9. Take a look at the timings (.ms) for notable passes; which passes to focus on depends on what I am testing
10. Copy the values to an excel spreadsheet to do a thorough breakdown. There may be trade-offs or unexpected results that may have been overlooked by only focusing on a few of the passes. These discoveries often leads to additional deep dive performance investigations
11. Document findings on a Notion page. This page is intended to be reviewed by core engine programmers, as well as artists or anyone else in the team who are interested in learning more details about the investigation
12. Create a Slack post summarizing the findings. Include relevant images that, at a glance, communicate the results of the investigation

Tech artists, core engine programmers, and select members of team discuss various topics related to the project’s performance during a bi-weekly meeting. During these meetings, I have been presenting results of various performance investigations

I take care to present in a way where “everyone gets a piece of the pie”; concepts are first introduced before diving deeper into the technical aspects of the presentation topic. I am genuinely interested in the topics I am presenting, and I hope to share my enthusiasm through the manner in which I present.

Supporting Data Validation with UE5 tech findings

Taking the results from my Nanite and Lumen investigations, I collaborated with the tech artist responsible for spearheading data validation efforts to validate the list of asset and level validators necessary for the project. These were items that were generally in-line with the established best practices, and were aimed to monitor and keep various aspects of assets and level construction in-check. Validators also looked for cases where a data mismatch would cause an error.

Errors and warnings are generated on the asset or level’s save; users won’t be able to submit the asset/level they have modified until the errors have been resolved.

Examples of Nanite/Lumen-related items that asset validators check include but aren’t limited to the following:

• WPO usage and disable distance (Nanite) – produce a warning when artists were submitting assets with WPO enabled. Also ensure that a WPO disable distance was set for assets requiring WPO
• PDO usage and clamping (Nanite) – produce a warning when artists were submitting assets with PDO, and ensure that a disable distance was set when using PDO
• Nanite Tessellation – produce an error when Nanite Tessellation is enabled, but disable fade distance is not enabled
• Enforcing the use of the Nanite LOD group

Examples of Nanite/Lumen-related items that level validators check include but aren’t limited to the following:

• ISM having WPO in Ray Tracing enabled (Lumen HWRT) – causes performance issues related to the recalculation of the BLAS, and should be disabled
• Flag meshes smaller (than a certain size) that have “Actor Visible in Ray Tracing” enabled (Lumen)

Developing and validating asset creation workflows

I have been working closely with environment and VFX artists to develop workflows with the following goals in mind:

• Consider UE5 best practices with the aim to keep performance in-check
• Allow for artistic flexibility; workflows should enable artists to create content that aligns with artistic direction
• Consider team size and resources available; leverage efficient workflows that maximize the amount of content created with a relatively small team

Workflows that have been worked on/validated include:

• Asset construction workflow vs Nanite performance
  • Manifold vs non-manifold geo construction
  • Nanite Tessellation usage
  • Foliage look dev vs Nanite performance vs Shadow Depths performance
• Nanite Tessellation vs “safe” magnitude range
• Scene construction workflow vs Nanite
• Scene lighting vs Lumen recommended optimizations and rendering settings

Fluid and fog tech R&D

Water and fog are two large topics for this project. Fog is crucial for establishing mood, and plays a large role in driving lighting and art direction. Water is also a major topic of discussion and is a multi-disciplinary concern between gameplay, VFX, audio, environment art, and tech art.

Fluid tech investigation

My area of focus regarding fluid tech investigation was to thoroughly research the various forms of fluid tech that was available to us. Options were generally either provided in the engine or can be enabled with an accessible plug-in. Understandably, each option came with their own pros and cons. It was important to assess not only how each option performed, but also each option’s workflow and whether they supported the project’s artistic direction and gameplay needs.

I had collaborated with a VFX artist on this research, and had built a gym together showcasing the various options that were investigated. The performance of each of the following tech were also investigated.

Notable solutions that were investigated include:

• The “simplest” implementation – tiled planes with WPO-enabled material to drive animated waves
• Niagara System solutions – Niagara provides various fluid simulation solutions
• Baked water simulation – A technique used on the Witcher 4 that also required the use of UE Landscapes
• Water body actors – Same solution as that in UE4, also requires the use of UE Landscapes. Default material has built-in support for colliders and wave animation, driven by Gerstner waves

Driven by the needs of the project, the results of the performance investigations, existing tech decisions, team size, as well as support each option would require, we chose to use the “simplest” implementation. Splash effects and ripples would be handled by VFX and wouldn’t be simulated in real time. A line was drawn by the tech director regarding the interactivity of water: the water won’t be interactable due to the amount of support the fluid simulation solution would require. It wasn’t impossible, but there were other places a team our size could be spending our efforts.

Fluid tech investigation was done in tandem with the water shader’s creation.

Material creation

Water shader

Regarding material creation on this project, most of my efforts have been focused on prototyping a water shader that was compatible with the chosen tech from the fluid investigations. As this was done during a time where the art direction was still being developed, it was quite an iterative process between myself, concept art, and the art director.

The intention of the tech director, and thus also the tech artists, were to allow concept artists to be creative with exploring different possibilities of what things in the project can look like. They shouldn’t allow the technical constraints of the engine limit their explorations.

Early in this process, I had worked with a concept artist to explore the physical properties and overall appearance of the shader. Concept art drew inspiration from “real world” materials, such as resin and acrylic paint; one of my initial mandates was to create materials that had the same properties as their real-world counterpart. Iterations of the shader would be sent to the concept artist for feedback, and were then presented during strike team show-and-tells to receive additional feedback from the team.

The actual “movement” of the material came with its own challenges; real world materials such as resin and paint aren’t normally animated! That in-of-itself was another iterative process between myself and concept art. It was still an active investigation by the time the art direction moved away from water inspired by art materials, and aligned closer to what real-world water looks and behave like.

With this shift of art direction, I had not only studied reference material of real-world water, but I had also visited the beaches in my city to record reference materials and observe wave motion in a large body of water. Through my own personal interest, I had spent time learning about fluid dynamics and had eventually implemented Gerstner waves in the material graph to drive the fluid motion. An alternative was to look into waves driven by FFT; this is something I intend to investigate in my personal leisure time.

After editing and iterating on the existing material to make it look less-like art materials, I eventually had my material approved by the art director regarding the final form of the shader.

Making it artist-friendly – wip

The final version of the shader was used by environment artists in a vertical slice level, where numerous parameters were exposed.

Water tech compatibility concerns

There was a balance that had to be achieved between the water shader’s appearance and its construction, vs the water tech we were using. At the time, the tech supporting the water material wasn’t decided on yet. However, the research that was previously done on water solutions was on my mind as I was constructing the material.

Performance concerns

The main performance concern I had regarding the water shader was Nanite compatibility.

• The use of WPO – A material using WPO on a Nanite-enabled mesh would increase the number of raster bins, directly affecting performance. WPO would need to be disabled at a distance.
• Material blend mode – Nanite is only compatible with opaque and masked materials; materials that are translucent or use SingleLayerWater isn’t supported. The use of masked materials should also be monitored, due to how it uses a more expensive rendering pipeline. A Pixel Programmable Distance will also need to be set to monitor this.

As a workflow implication, water meshes would need to be tiled across the map to allow for disabling WPO and PPD. The material itself would also need to seamlessly tile between the different water meshes.

Contributing towards project-wide tech decisions – wip

UE5 has numerous new tech; whether we wanted to go with a particular tech was dependent on a few factors, including:

• The needs of the project (what we were trying to create vs what the tech can provide for us)
• The performance implications of embracing a certain tech
• Dependencies the tech has on each other; will picking one mean we’ll need to automatically pick another?
  • For example, this was definitely a case for Lumen and Nanite; going with Lumen meant we would have to have most assets Nanite compatible/Nanite enabled

On the art side of things, the tech we had to decide on were things that would directly impact asset and level construction. Some of the tech that we needed to make a decision on included (but aren’t limited to):

• Nanite – seems to be a given if using UE5, but still something to confirm given the workflow implications using Nanite has
• Nanite Tessellation – comes with a real workflow and performance implication
• Nanite Landscape/UE Landscape
• Lumen – whether to be using SWRT or HWRT, but eventually, discussions would need to be had regarding standalone HWRT features (if using HWRT)
• Virtual Shadow Maps – seems to be a given to use them given how it works with Nanite, but has some real performance concerns
• Megalights
• World Partition – would enable the use of Far Field if we decided to use HWRT, assuming World Partition HLOD1s were built. Also greatly impacts workflow
• OFPA – a given if using World Partition, but has huge workflow implications across the board (not only for artists)

Project-wide rendering settings validation and implementation

We had migrated to a new repository to mark the beginning of production. Core engine had given tech art an opportunity to implement list of “final” rendering settings to the DefaultEngine.ini file of the new repository. I was the tech artist who took responsibility over this effort.

The list of decided-on cvars to implement were a result of the following:

• Combing through list of cvars from the previous repository, and ensuring that the settings aligned with the latest tech decisions
• Established best practices
• Recommended settings that were validated regarding performance gains and visual impact

---