Developer Updates
Developer Insights #23: Black Hole Sun
April 5, 2024
In celebration of the total solar eclipse, I wrote a developer insights blog post with AJ Christensen, a Senior Visualization Designer with NASA. In the first half AJ dives into what a solar eclipse is, and what to expect when viewing it in real life, while in the latter half I breakdown on how we handle eclipses in KSP 2. 
To do this, we track our nearest celestial bodies and use mathematic formulas to determine whether or not two compared bodies overlap. From there we solve for the percent visible and attenuate our lighting and lens flares appropriately.

Houston, we have a planet: The spherical terrain of KSP 2
March 22, 2023
During this guided panel discussion at GDC I go over the custom global illumination and reflection render pipeline we use in KSP 2 to help elevate the look of our celestial bodies in the Unity game engine. By modifying the diffuse and specular pass in the render loop, we are able to create a convincing, yet light-weight, runtime sample of the space around our camera. This allowed for better bounce light ambient and reflections throughout the in game universe.
Developer Insights #11 - Engine Exhaust Visual Effects
September 17, 2021
In this developer insights blog post I go into detail on the pipeline behind one of our more complicated visual effects: the engine exhaust. I summarize how the process moves from planning to previsualization, to mesh manipulation and finally over to how in game values interface with the final look in the shader.
More of my work
Custom Render Pipeline
To improve the visual fidelity of our Unity game, I pushed for a modification of the render pipeline we used. With our custom render pipeline, I was able to implement a more accurate runtime diffuse and specular global illumination based on cubemap samples of the scene around the player's camera.
Because our game has both a local space (terrain, environment, vessels) and a scaled space (celestial bodies), I was able to establish an efficient render pass that only rendered the scaled space celestial bodies into a cubemap. This cubemap is then sampled at a high mip value to achieve a blurred look in the diffuse GI calculation, and then sampled at a low mip value to maintain it's reflective look in the specular GI calculation.
The following screenshots are from our GDC panel and show the above custom rendering work. In the left image the rendered cubemap appears in the top left. The diffuse is applied to the entire scene, but its' most visible in the middle test sphere and on the vessel at the focus of the scene. The result is a pleasant blue to green gradient, mirroring the environment around the player. In the right image the specular results are more obvious in the ocean shader. With the custom cubemap we are able to have things like our large celestial bodies and even the galaxy cubemap reflect in the ocean accurately despite existing on a spherical world. 
Diffuse GI Sample
Diffuse GI Sample
Specular GI Sample and Custom Render Kit Editor
Specular GI Sample and Custom Render Kit Editor
Visual Effects
I built and supported the asset material library for the visual effects in Kerbal Space Program 2. By far the engine exhaust was the most fun to work with because it's physically accurate to what's described by our subject matter experts, changes dynamically in game under different levels of pressure and, in my opinion, looks amazing when at full throttle when combined with the heat distortion shader and post processing.
Mesh without exhaust material
Mesh without exhaust material
Color control on exhaust material
Color control on exhaust material
Blendshapes for pressure transitions
Blendshapes for pressure transitions
Full throttle with distortion and lighting
Full throttle with distortion and lighting
One of the greatest challenges for Kerbal Space Program 2 in terms of visual effects was the reentry effect. It needed to be a mesh that could expand around any part, and occlude visually to not show incorrect heating. For the reentry shader, I was able to assist the Graphics engineers by adding a few features like soft particles, near clip fading and some other artist editable properties.
My contribution to the reentry pipeline was creating the tools within Unity to view, modify and batch bake all reentry meshes for all 400+ parts in our roster. Using Houdini's Unity API, I designed a seamless tool for artists to bake everything within the Unity Editor and work directly with their prefabs. On top of that I also created a batching tool that could bake all the reentry meshes for our parts within minutes, as opposed to the weeks it would have taken either wise.

Reentry featuring an animated heat shield part and heating occlusion

Procedural Texturing
Kerbal Space Program 2 has a variety of procedural parts that have their materials update whenever the player modifies the different sliders in the Wing Shape panel. These parts were a fun challenge! I worked closely with our technical animator and principle artist to bring these wings from idea to prototype to final asset in game. 

Small Procedural Wing

Medium Procedural Wing
Post Processing
Another one of the dynamic rendering systems in the game is the post processing system. With it, environment artists are able to modify their own Post Processing Profiles, set the blend in/out altitudes and opt into having several for different times of day.
It also supports custom post effects like the virtual tutorial overlay that features a CRT vignette and a digital outline.
Post processing near the Kerbol star
Post processing near the Kerbol star
Custom virtual tutorial overlay
Custom virtual tutorial overlay
Lens Flare Occlusion
At release, the sun's lens flare occlusion was based on a dated raycast-collider implementation. This led to a number of visual issues. Some of which include: more complicated parts hiding the star with their primitive colliders or terrain and ocean not properly occluding the lens flare.
To address these issues, I worked to update the system with a command buffer and async GPU readback to determine just how much of the star was visible to the player's camera. I would render a small disc the apparent size of the sun at the far clipping plane, and then using the depth buffer, determine how many pixels were visible to calculate a "percent visible" to scale the lens flare with.

Credit: Intercept Games
Link to Forum Post

You may also like

Back to Top