Experimenting With Features for Large-Scale Game Projects in UE5

Introduction

My name is Kimmo Kaunela and I’m a Tech Artist from Finland. I’m currently focused on creating environment art and various tools for that. 

I started my adventure with game art over 10 years ago and I’m currently working on a few game projects in a small two-dev team where I’m responsible for the visuals. The rest of my time goes to making products and packs for Unreal Engine Marketplace.

The First Unreal Engine Project

My history with Unreal Engine goes way back. I started using the Unreal Development Kit, more widely known as UDK, around 2013. Most of my projects back then were focused heavily on environment art but I also started to learn more about how shaders work. I also used Unity during that time for professional work, but I always felt more at home with Unreal Engine 3 because of the more artistic-friendly approach of various tools like the famous node-based Material Editor.

In early 2016 I started using Unreal Engine 4. It was a huge step forward from the UE3, but some tools still felt similar to those of UDK. The lighting system was more advanced, rendering supported PBR (Physically Based Rendering) and I also started to play around with the new Blueprint system.

In 2017 I started to work on a VR game project that was using Unreal Engine 4. Our team was only two developers strong and that meant that I needed to really focus more on technical things and not just environment art. I didn’t have any previous programming experience, so I had to start learning how object-oriented programming works and then translate it into Blueprints. That really empowered me to be more than just an artist and I was able to start creating gameplay systems that helped me to prototype various ideas really fast.

Epic Games also used Unreal Engine for their own games and that made it feel like a complete software package. I think that was another advantage of Unreal Engine – it contained lots of native tools that worked well together. I could use Blueprints to drive materials, lights, and animations without using any third-party tools or plug-ins. That made it a powerful system and I slowly found myself working more with these technical things than just creating art.

I shared some of my work on social media and people started to ask if I could share these tools. Pretty soon I realized that I could turn these tools into a more generic tool library that could help other UE users to speed up their projects. I started to create UE Marketplace packs that contained environments that featured these tools. Users could also then edit these Blueprints and make changes if needed. This made it a powerful ecosystem where I could see some practical use cases in my projects that could benefit from these tools and then share these generic tools with others.

Unreal Engine 5

I was amazed when I first saw the Lumen in the Land of Nanite Unreal Engine 5 tech demo. It looked so realistic, and the lighting was the first thing that caught my eye. That UE5 announcement really came from nowhere and I wanted to know how these new features work. Epic Games didn’t share much info, so users were left to speculate how Lumen might really work, what kind of magic Nanite was using, and so on. That generated huge hype and people were really anticipating the moment when they could try it.

I also felt some pressure because I started to think about how all the previous workflows might work that I’ve been using in my previous projects. I saw a huge potential with Nanite but at the same time, I thought that my projects wouldn’t really benefit much from it because I didn’t use Megascans assets or anything that would really benefit from that micro polygon tech. I started to ask questions like will Nanite break older and existing meshes, how heavy is the new Lumen lighting system, what material tricks might still work with Nanite meshes, can I still use decals, vertex colors, tiling materials, and so on.

Luckily Epic Games released the first early access version of UE5 in the Summer of 2021 and I finally had a chance to get some answers to my questions. Fortunately, most of my worries were unwarranted.

As an artist, it felt awesome to finally play around with Lumen and test how Nanite handled meshes in practice but as a game developer, I felt that there were too many things still in progress and buggy. I also noticed a lot of issues with basic Unreal Engine features like physics and performance. Some of these issues were fixed in later updates but few of them still exist today. It was also reassuring to know that I was still able to use most of my older workflows, but I could also mix them with these new features like Nanite when possible.

Transferring Projects

I had around 17 different UE Marketplace packs that I needed to transfer from UE4 to UE5. It was a huge job that took over two weeks in total to complete. On top of these, I needed to transfer a much larger game project that is still causing issues.

In theory, it’s possible to easily transfer older projects to UE5 if the project contains mostly visual things like meshes and materials. Unfortunately, most of my projects were much more complex, and that’s why I encountered my fair share of issues.

My process went like this, I duplicated a project and then opened it in UE5. During this process, it will ask to convert the existing project to a newer engine version, and I usually just select the Convert in Place option. Depending on the size of the project and the system specs, this can take a long time to convert and open the project because Unreal needs to compile lots of shaders, generate mesh distance fields, etc. After that, I would look if there are any errors, and then I would start to convert older assets to work with UE5 systems. Epic Games made a few useful videos that showcase this process better:

There are some built-in tools and plug-ins that can also help to convert older meshes to Nanite meshes and older Cascade particle systems to Niagara systems. My experience is that these tools will work fine in 80% of cases but more advanced meshes with complex materials and particle effects with many emitters can cause issues. I’m sure these tools will get better over time and Nanite should also get updates to support more material types.

In the meantime, I would recommend reading documentation and manually changing assets that these tools can’t handle in some cases. If you see meshes with the default Unreal Engine checkerboard material, then most likely that mesh is converted to be a Nanite mesh but it’s using a material that isn’t currently supported with that system. In these cases, you should disable the Nanite mesh option.

If the project contains any Blueprints, then there will most likely be a few warnings about some deprecated nodes that you should change to newer ones. Luckily the Blueprint system is pretty much the same in UE5 as it was in UE4, so you shouldn't get errors, but I would still recommend testing that everything works. For example, the current World Partition implementation can break some Blueprints at runtime if those Blueprints are using the Construction Script to add child actors.

The new Chaos Physics engine might bring some issues too. Most of the physics features are automatically working in UE5 but you might need to tweak some values for things like physics constraints and such. If the project was previously heavily relying on PhysX features like destructions or vehicles, then you need to do more manual work. In the case of the PhysX vehicle class, you need to enable the Chaos Vehicles plug-in and then reparent the Blueprint, replace nodes, and set up correct settings for the engine and wheels. This way the vehicle can use the new Chaos Vehicles class.

Lighting should work without any huge changes unless you were using something more complex in your UE4 project. If you want to use Lumen, then that would need a few things to work properly like a sky atmosphere or similar actor in your map. The Unreal Engine documentation is very good to help with this topic. Other than that, you can keep using the basic dynamic or baked lighting like in UE4.

Lumen

Most of my projects are featuring large environments with dynamic day and night cycles, so baked lighting would not work that well. Previously I needed to have a lot of different local post-process volumes and even local lights to handle different lighting scenarios. That is far from perfect and can end up feeling like a huge hack that will cause all sorts of issues. 

The worst-case scenario for me is when I need to set up lighting for post-apocalyptic environments that contain both exterior environments and interior areas without any artificial light sources. In real life, the sun would be the only light source and its indirect lighting will then light abandoned interiors. In those cases, I previously needed to have some sort of way to handle indirect lighting and without a costly ray tracing, it was very hard to get good and realistic results with dynamic lighting.

Lumen was a huge game-changer. It can make interiors to be darker than the outside but also helps to bounce Sunlight more. This way, lighting is more dramatic and in terms of gameplay, it can also help the player navigate because the bright sunlight is illustrating where doors and windows are. A new post-process setting called Local Exposure also helps to boost interior lighting to avoid getting too dark areas. Another beneficial part of Lumen is reflections that help with material definition and make sure reflections are always matching the surroundings.

Lumen also features different modes, a so-called Software Lumen and Hardware Lumen. Software Lumen is relying more on on-screen space tracing and distance fields and Hardware Lumen is tracing more against triangles so it can support skeletal meshes like characters. There are certain limitations with this system currently that are good to keep in mind. Most of them are related to how Lumen works so it’s a good practice to split meshes into smaller ones that will allow keeping distance fields and surface cache to be more accurate. You can read more about it in the Unreal Engine 5 documentation.

I think Lumen is the biggest game-changer for me in Unreal Engine 5. I had a few projects that were previously using baked lighting in Unreal Engine 4 but with Lumen, I was able to get good results without any baked lighting. Lighting is the thing that can make or break the look of a scene, and Lumen is really helping to showcase meshes and materials better. There is still some light bleeding and inaccuracy when using the software version on Lumen but I’m sure Epic Games will solve that in future engine updates.

Procedural Generators in UE5

The end results might look complex, but the actual blueprint logic is still simple under the hood. Usually, a program like Houdini is used for procedural generators and that can also offer a lot more control compared to what you would get by simply using Blueprints. I personally think that Blueprints are still handy for simpler things that can then be expanded based on needs. It makes working a bit easier too when everything is happening inside Unreal Engine with functions that you can also access at runtime if you need to.

No matter the tools or language, these kinds of systems usually have inputs that will then lead to some results and these inputs can vary a lot from simple numbers to more artistic methods. Basic primitive shapes can also work as an input like spheres and boxes. This is a good way to find random points where to spawn something. Not many might know this, but splines are also good input methods for many tools. In practice, all these methods can be used together to speed up some parts of the level creation process.

All the used methods are built in Unreal Engine because they are also used for games. You can use different tracing methods to find locations where to add instanced meshes, actors, sounds, and so on. For example, you can have a parent tool Blueprint class that contains all the functions to drive a logic that will scatter meshes inside a box. It can contain a structure variable that holds different variables that specify what meshes it will scatter, how densely these would be scattered, and so on. Then you can have child Blueprints inherited from this parent class that can have different structure values. This way you can have a basic preset system where one child Blueprint can scatter grass and another can scatter debris, etc. You can then use a spline-based Blueprint that will add these child actors along a spline and that way easily add details to your map.

These procedural generators are still using Blueprints but instead of running functions at runtime, these systems will use Construction Scripts. Construction Script will basically run every time the actor is placed or spawned into a map so it’s possible to use them in the editor while creating maps and to iterate faster.

Another way would be to use editor events to drive these functions in the editor and see end results. There are limitations to what is possible to do this way and Construction Scripts can also run into an issue where there are too many loops for Unreal Engine to handle.

I have loosely divided my tools into three different categories. There are structure Blueprints that help to generate large assets like buildings and roads and are using basic inputs like how wide or long something is. Then there are spline-based Blueprints that are using a spline that the user is specifying for it. Based on that spline, it can add lots of things like actors, debris, spline meshes, pillars, etc. The last category is decoration Blueprints that help to scatter things locally. Usually, these systems are using a simple collider shape that will specify the area where it will add things.

A good example would be the building system that I’ve been creating for the last few years, slowly feature by feature. It can use a mesh library and create exterior and interiors, scatter furniture, add stairs, scatter things like foliage, etc. Everything is still 100% using Blueprints. My future plan is to see if I can combine these systems with Unreal Engine 5 geometry tools so that instead of creating meshes outside of UE, the system could automatically generate them based on different scenarios.

There is so much that I could share about these systems but in the meantime, you can find more info about these tools in my newsletter and most of these blueprints are also available on the Unreal Engine Marketplace. 

Using Chaos Vehicles

Previously I was using the PhysX vehicle class which worked pretty okay, but it was really hard to make it work smoothly. Another issue with that system was the fact that it didn’t get many updates during the years so unfortunately, some bugs are still present. PhysX vehicles might glitch and jump when colliding with other physics bodies and shake when runtime performance drops below a certain limit.

Chaos Vehicles is still in beta but already it works much better than the PhysX version. It’s much smoother to drive and there’s not that much glitching even if the performance drops low in some cases. I also like how much more control it offers compared to the old PhysX version. Another cool thing is that the CV system can support any number of wheels so it’s possible to use that for things like bikes and such. There is even an option to use spoilers that affect the driving or choose to use more arcade-styled driving.

Chaos vehicle system works almost the same way as the PhysX equivalent and the documentation is pretty good and useful. It’s still possible to use an animation Blueprint that will allow you to move and rotate various parts on the under chassis based on the wheels like springs and axels. Other than that, you can simply tell what bones are going to be wheels and the system will be able to work from there.

Setting Up Destructions in Unreal Engine 5

The New Chaos Destruction system can generate very good results and it’s a huge step forward from the old Apex Destruction system that Unreal Engine 4 used. Despite all that, most of the time I’m just using the good old way of handling destructions where I just enable physics for different mesh pieces and then give some impulse to make them fly away. This will still look pretty good with a nice particle effect to hide the way it really works.

I used this same method with the destruction that I made for the outer space project. When the structure gets damaged enough, it will trigger an event that will use a loop to set physics enabled for meshes and then generate random impulses to set them to fly away from their original position. The system will also add explosion effects for these meshes to hide the breaking part a bit. It’s not perfect and there are still some cases where these broken pieces will get stuck because there is not much gravity in space that could help to limit that behavior.

I still need to learn more about the Chaos Destruction system to be able to use it for this kind of things. My small Chaos Destruction tests have shown that there is a lot more control to break meshes using that system so I might start using it more.

Traffic

I wanted to have some traffic in my outer space project where spaceships would fly on different routes and that way make the environment look more alive. I didn’t have any NavMesh data that I could give spaceships some points where to fly. That’s why I decided to create a more fake version that could simply work as background traffic. Even though this system is faking the traffic, I still wanted to have enough control of how these ships will fly to have more organic results. 

The traffic spline Blueprint will simply move these spaceship actors along a spline but each of the ships will have its own data for speed, offset, and color theme. This way each ship can fly at a different speed and location to avoid colliding with other ships and look a bit different compared to others. The system will randomly choose these values based on the number of spaceships it will add.

Even though the system was this simple, it still allowed me to create good-looking traffic that looks reasonably realistic from far away. The system also includes settings to optimize the runtime performance so instead of using spaceship actors, it can simply use static meshes. I might revisit this system soon and implement more logic to it.

Conclusion

I would really like to spend some time with the new geometry tools and see how I can use them with my other Blueprint tools. Chaos Destruction is also something that I want to test more and see how to break stuff safely.

I have to say that I’m not a huge fan of the fact that Unreal Engine 5 is so massive and contains tools, plug-ins, and features that you don’t really need for game development. I fully understand the reasons for this change and all the possibilities of how different industries can utilize the Unreal Engine, but I think there should be a better way to handle this extra complexity. Epic Games expanded their focus with Unreal Engine 5 to cover lots of different use cases from games to virtual productions and films and unfortunately, it feels that this new, larger scope also means that there will be more bugs and issues with basic features that anyone should trust to work when making games. That’s why I would like to see Epic Games focusing more on the actual QA testing for future releases and not just focusing on adding new features while keeping the rest of the systems in the experimental or beta stage.

Because of that, I’m still using Unreal Engine 4 for a few game projects that I’m currently working on. I think that Unreal Engine 5 still needs some time to mature a bit. Hopefully, during that time Epic Games can also expand the use of Nanite and optimize Lumen more.

I can see huge potential with Unreal Engine 5 and in terms of computer graphics, it really turns a totally new page. I can really appreciate the hard work they have put into these new technologies that are removing some walls that were previously there. It’s kind of humbling to think that anyone can download this piece of software for free. Looking back at those early UDK/UE3 days, I can still see how Epic Games is continuing its chosen path to give more power to artists like me and you. We just need to learn how to use all of that.

Kimmo Kaunela, Lead Environment and Tech Artist

Interview conducted by Arti Burton