Work Log

  Procedural Generation Runtime Compliance     Over this week I have made major progress on the packaging errors that effected the project; the majority of which had to do with the systems of generating procedural meshes and textures at runtime. The reason they weren't runtime compliant is that I was using functions and variables from the engine that were marked as WITH_EDITOR or WITH_EDITORONLY_DATA which are not allowed to be used in packaged builds of the game/ at runtime. Procedural Meshes:     With the main appeal of the game being the generation of planets I decided to start by fixing the mesh generation system. In the process of looking for a solution I came across two articles ( article 1 article 2 ) on the subject of runtime procedural meshes written by an employee of Epic Games. The first article was the one that I spent most of my time on but they are both very detailed on their respective topics.      After multiple days of trying to implement solutions put forth by Ry

  Real-Time Planetary Lighting in UE4 ft. A Lesson in Building Early and Often     The final feature I wanted to improve before moving to the pre-alpha was the lighting. Early on in this project I decided that the lights in the engine wouldn't suffice. The point lights didn't have a large enough radius to be effective in a solar system, and lighting planets lit with individual spot-lights wouldn't be feasible when it cane to asteroids. Thus I implemented a system of unlit textures that would emit color only on faces whose normal was pointing towards the sun. This system though didn't have support for two features that I wanted with the lighting: reflections and shadows. The Directional Light Solution:     Before attempting to rewrite the lighting system, I decided to give the built-in  lighting one more chance. I'm insanely thankful that I did this because while doing some googling I found this thread on the unreal forums that explains multiple methods of lighting

  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,

  Solar Niagara Effects & Asset Cleanup in UE4     I had two goals for this week: to make the stars more interesting in their material and added particle effects, and to get assets to be automatically cleaned up (deleted) when not in use. Solar Effects:     Looking at pictures of the sun, it is clear that the surface is much more than a smooth plane. There are bright spots, dark spots, swirls of fire, and ribbon-like structures that dance on and away from the surface.     I only made very minor changes to the material to mimic these effects. These were changes to the noise and to the color to make more bright spots appear and less black. The rest of the changes, like the solar flares, had to be made as particle effects.     The solar flare effect can be broken down into 3 main parts: spawning, adding initial force, and adding noise force.     The flare emitter loops infinitely but each loop, it chooses a new location and burst strength.  CMELocation  is a float2 that corresponds to

Asteroid Heightmaps in UE4     The task for this week was to make asteroids more interesting by having their meshes not be plain old cubes. The original plan was to basically copy the terrain generation system from the terrestrial planets, but instead I tried challenging myself by creating a world displacement material instead. Method of Terrain:     Starting out this feature I intended to copy, essentially line for line, the terrain generation process of terrestrial planets. This wouldn't have been terribly difficult but would defiantly have been very boring, so I looked for an alternative.      I knew from messing around in the editor that you can offset vertices of a mesh through a material, so googling that led me to a video which explained all the ways you can fake depth through a material. This video also introduced me to tessellation which adds more vertices to the mesh during the vertex shading stage of a shader (or material in UE4).       From the information in the video