Work Log

    This week I continued working towards the next milestone while simultaneously finding some bugs with existing functionality and taking care of them. Milestone Tasks     I finally updated the roadmap this week with the tasks I'm aiming to include in the 1.2 update. The deliverables are as I described last week along with fixes and improvements that will be added on an ongoing basis as I find them.      As for completed milestone tasks, I'm still mainly focused on the implementation of randomization. I was able to get full implementation done for Asteroids, Gas Giants, and Ring Systems. While completing each of these tasks however, I found some bugs with the functionality of the systems. Many of the bugs had simple solutions. Like the issues with asteroids were resolved by pausing the asteroid Niagara systems a frame after they were spawned. I also managed to complete the polish task for the overview camera which went off without a hitch. I'm glad I ...

      This week I have been focused on fixing some issues that have been lurking for too long and preparing for the next release.  Fixes | Normals Fix     The major fix I worked on was to address the broken normals on terrestrial planets. This issue has existed since the first iteration of terrestrial planet generation when I started calculating normals/tangents for the mesh. Back then the issue was limited to the borders between mesh faces where the vertices that were being calculated would end abruptly. Back then I thought it was passable as it was a purely visual issue that was confined to a limited number of border regions. However, when I parallelized the calculation a few weeks ago it became apparent that I would need to solve the problem now.     The implementation of the parallel calculation led to more of these borders as each subface would be adjacent to multiple other regions. These resulting borders were then visible across every fac...

      This week I enabled python in the project and I've begun the process of adding randomization to the planets. Python     I wanted to enable python scripts for the project because I knew that Unreal supports it, but I've never tried it. It's also been a while since I used Python and I wanted an excuse to use it again. The simplest use-case I could think so use it for was to generate the skybox texture. This would involve interfacing with the editor world, accessing actors from the world, and executing preexisting C++ code on said actor. All basic building blocks of things I may want to do in the future.     I began by following the official Unreal docs , and I was able to get it up and running relatively quickly. I did hit a small snag in getting PyCharm to recognize the interpreter that comes with the engine. But of course I wasn't the first to have this issue and as always the forums were able to guide me through it. Once I had the interpreter a...

      The past two weeks I've been working to multithread and optimize the terrain generation in Mini Solar System and it's finally paying off. I left off last week with a mostly optimized but partly functional system, and I'm pleased to say this week I have ironed out most of the wrinkles and the terrain generation is almost ten times faster. Setup     As previously mentioned , the old system would use one thread per terrain face, but now we are calculating the same face in parallel with multiple threads. I settled on an approach with the task graph system where one task would be launched to calculate the vertices, UVs, and tris for the mesh as well as the normals and tangents. Then that task would be used as a prerequisite for another task back on the game thread that would compile the terrain data from each thread and build the final mesh once all threads were finished. It had to be done in two separate tasks like this because the procedural mesh component ca...

      This week I grappled with Unreal Engine multithreading some more. I'm trying to make the terrain generation as efficient as possible for the planets, and that has consisted of lots of trial and error, and several rewrites, which means learning!      I came across this great Unreal Fest Gold Cost talk from 2024 which explains UE multithreading and how to use it. I'm surprised I hadn't come across this before because it has lots of great info. The biggest revelation I had was that I was using the wrong method of multithreading for what I wanted to do. Before this week I was using an FRunnable to calculate the terrain. In the talk however, Alex explains that these  FRunnable s  are meant for larger lifecycle tasks and are intended to be kept running. For my use-case though I want more fire and forget type functionality. Give a thread some info, let it run its calculations, and give the resulting data back to the game thread whenever it's done...

      This week I decided to try my hand at optimizing and improving the multithreading that is used in the game. I wanted to make it faster because the way it was implemented would cause the initial level load to take minutes if you had many terrestrial planets or cranked the quality level up in the settings. Background     I first added multithreading to the game in early October of 2020, and I covered the process of doing so in the "Multithreading Hell" post. I remember it being a frustrating ordeal at the time, but with years more experience under my belt by now I figured it would be a good a time as any to go back to it.     Multithreading is only utilized for the generation of terrestrial planets. Terrestrial planet meshes are made by evaluating noise at coordinates on a sphere. The sphere is made by taking points on a cube and normalizing them from the center. The sphere can then be neatly divided into six faces. The old approach would use one ...