TARAS TERESHCHENKO

Regardless of the complexity of the system you create, there will always be hidden nuances that are not immediately obvious. Every time you come back to it, you need to relearn it—search through the code, data assets, and sometimes even run experiments to make sure everything works as expected. Below, I will provide an example of documentation that saves a huge amount of time for everyone who works with this system. Vehicle Damage & Lighting Framework This document contains a set of rules that define how functionality should be developed and organized. Two sets of textures exist simultaneously: intact and damaged. Each damage zone has a corresponding mask used to reveal the damaged version of the material. Each damage event must include the index or indices of the damage zones, as well as the speed and direction at the moment of impact. The direction and speed are required for spawning particles. Each state is triggered by calling its corresponding function. Each function has an ...

Recently, much of my work has been related to PCG systems and content generation tools. An interesting aspect of this work is that these tools were not used only by humans. As the system evolved, it became increasingly clear that tools convenient for humans are not always suitable for AI. Conversely, solutions that work perfectly in an automated pipeline often turn out to be inconvenient for manual use. Over time, the difference between these two approaches became so noticeable that I began to think of them as two separate classes of tools. In this article, I would like to share several observations about how PCG tools designed for humans differ from tools intended for AI use. Determinism and Result Stability The first and perhaps most noticeable difference is the required level of precision in how a tool behaves. Those who have observed the Spline Sampler in Unreal Engine 5 know that sometimes you need to slightly adjust the spline in the level to get the expected result. For ...

At least three times on different projects, I’ve had to create a class that includes all the necessary components for lighting. It was used for dynamic day–night cycles, weather anomalies, and simple presets. Each time, I rethought and improved the system — simplifying it further and aiming to make it universal. I think now is the right moment to share my approach to organize the structure of this class. I’ll start by saying that in my system, any lighting state is a “preset,” or an interpolation between presets when it comes to dynamic changes. Each preset is a data asset. Below, you can see the structure for storing the settings: The function for updating the current components, the function for saving the current settings into a preset, the function for reading a preset, and the function for interpolating between presets — these are the foundation of the class. Everything else is specific to the individual project. You can certainly light a level without a lighting manager. However...

 A large number of game studios use assets from various libraries as placeholder content, as a foundation for polishing, and in some cases as regular content for development. But what happens when the team starts thinking about a systematic approach to performance and flexibility? Of course, a pipeline appears, followed by the realization that content from different sources is completely inconsistent, and all textures need to be converted to a project-optimized workflow. It’s hard to believe that any experienced specialist hasn’t faced this problem before. In this article, I want to share how I accelerated the process of transitioning to a unified pipeline. Texture Converter This tool was created to simplify and speed up the task of unifying texture assets in the project. It generates new textures by combining channels from multiple source textures. The process takes place directly in the editor, without export/import and without relying on third-party applications. The most common...

Water surfaces are an essential part of game projects. The approaches to implementing them are constantly evolving, where visual quality and performance are still in conflict. I’d like to share a bit about my experiments and thoughts on this topic. Trochoidal wave The shape of a trochoid is the key to understanding the mechanics of a water surface. A trochoidal wave is a model of a surface water wave where the water particles move in nearly circular or elliptical paths, creating waves that have rounded troughs and sharper crests. It’s a more realistic representation of ocean waves compared to a simple sine wave. In simple terms: The wave shape is smoother and more natural-looking, with sharper peaks and flatter bottoms. Water particles don’t travel far; instead, they move in looping paths — mostly in place. This kind of wave better represents how waves behave on the ocean surface under light to moderate wind conditions. Prebaked spectral waves  My prebaked solution uses spectr...