Progress Update #19

 Orbit Debug/Visualizer Optimization


    This week I tasked myself with optimizing the orbit visualizer. The reasoning behind this was that I couldn't render an entire orbit of planets with large orbit radii without the framerate plummeting to the low teens and that would need to change.


Finding the Root Problem

    The first thing I set out to do was to find out exactly why the engine was having a hard time with rendering orbits far into the predicted future. While looking for methods of debugging optimization in Unreal, I came across a presentation by the Unreal team on Profiling and Optimization in UE4. This talk introduced me to the stat unitGraph console command as well as the GPU Profile accessible with the shortcut Ctrl + Shift + ,
    Through these methods of debugging I realized that the debug line method of rendering would hit the CPU render thread (draw) while the spline method would hit the CPU game thread.

Baseline
(0 steps)
Debug Line
(15,000 steps)
Spline
(1,500 steps)

A Third Approach

    It seemed that neither method or drawing the orbits was going to be perfect, so I tried looking for a different solution. I found that surprisingly there were many people inline trying to do exactly the same thing I was with visualizing celestial movement. In one of these forum threads someone had suggested using particles, so I made a test Niagara system. It wasn't long before I discovered ribbon particles. These particles are very strange, and I'm still not sure if I know exactly how they work, but from what I can tell they are pretty much in between a debug line and a spline. 
    With a little tweaking of particle spawning I was able to get a very good result. With 2,000 steps (@ timestep = 1) the furthest planet in the solar system (250,000 units) was able to show a full orbit of the star as well as having enough detail to show the orbit of a moon on the closest planet to the star which completed 5.75 orbits.


    But because apparently nothing will ever work perfectly, the ribbon orbit visualizer cannot be shown during gameplay because of the way particle spawning works. I really want to put more time into fixing this at a later date because the ribbons are the most performant out of the three methods, but for now I decided to try to optimize the ones that would work during gameplay.


Optimizing the Debug Lines

    I couldn't find anything online on how to reduce the load on the CPU draw thread, which is what the debug lines hit the hardest. Because of this I started looking at what I could to do reduce the amount of prims. As you can see in the first set of pictures the prim count for debug lines jumps up tremendously from the baseline which is what made me think that reducing that number would help.
    I tried to figure out how I could render less lines and still get the same effect. This gave me the idea to draw only every nth point. Thus I came up with this solution:


    Using the same settings as the initial test (NumSteps = 15,000) this time only rendering 500 steps (RenderedSteps = 500) I was able to get the same visualization as the ribbon, albeit with detailed orbits (e.g. a moon) being more jagged. Though it is now very performant and keeps a steady framerate in-game.



Optimizing Splines

    For the splines I did almost exactly the same thing. Only with splines, since they can curve, the RenderedSteps can be even more aggressively turned down because the inherent curve of the spline will fill in the missing information.


    With the same settings as the aforementioned debug lines (NumSteps = 15,000 : TimeStep = 0.2 : RenderedSteps = 500) the splines achieve the desired 120 fps mark with general orbits being correct but fine orbits (e.g. moons) being almost completely useless.



    I could probably optimize this even more by finding out why/what part of the splines is taking up so much CPU power and trying to disable it, but that will have to be done another time.


Final Code:



Singleton Implementation!

    This week I also finally got around to properly implementing the OrbitDebugActor as a singleton. It was pretty simple, with the relevant code being:

OrbitDebugActor.h

OrbitDebugActor.cpp


    Line 1 of the .cpp was because I was having a unresolved external symbol error on _instance in the .h and this solution was brought to my attention by a stack overflow thread. 
    
    The singleton can thus be used like this:

CelestialGameMode.cpp

Comments

Post a Comment

Popular posts from this blog

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more

Progress Update #13

Image
  Niagara Asteroids in UE4     These past few days I have continued work on asteroids. Only that now I have ditched instanced static meshes in favor of getting my hands on the new-ish Niagara particle system.  Learning Niagara     I have decided that since this is an entirely new subsystem of the engine I would do everything in blueprint first, then transition everything to C++ when I knew it was working reliably. Additionally, because Niagara is still relatively new, the official documentation is sparse if existent at all. So with most tutorials at this time geared towards blueprint implementation, starting in blueprint will give me the highest likelihood of finding a solution to any problems I may come across. The Niagara Workflow     The first thing I learned about Niagara is that the workflow has changed significantly from what cascade was. Where in cascade (to my limited knowledge) you worked in one particle system where e...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more