Developer Insights #11 – Engine Exhaust Visual Effects

[Aaron VFX]

On 12/18/2021 at 4:28 PM, TLTay said:

I'm not a game developer or effects artist, so my ideas are probably irrelevant, but why not...

I learned a lesson from my first visual effects boss in the game industry that I carry with me to this day. When I started, I came in with a video editor background. I didn't know how video games were built. My boss would ask me, we need to make a healing effect for this carbunclo, what should it look like? I would go on to describe what I thought would look cool, giving no care about if it was even possible. He would then twist his brain to figure out how to make it happen with the tech and tools we had. 

Since then, I make a point of getting input from other disciplines on what they would like to see, how they would do something or what could be better from their perspective. Others are not bound by the thoughts of limitations, tools, or technology that an expert in a subject may be. When I get others perspectives, I twist my brain to figure out how to make it happen with the tech and tools that are available.

Thanks bossman Gordon.

Trip down memory lane aside, I fully embrace the discussion of ideas from different perspectives.

[HB Stratos]

20 hours ago, Aaron VFX said:

Not sure what we can do with tweaks to visibility based on lighting conditions but I'll take note and look into it when I can.

I've researched a bit, looks like this will not be too easy. Waterfall uses additive shaders for the luminous exhaust plumes, which makes a lot of sense. However this makes it difficult to make an effect change with ambient light as it is always drawn 'ontop' and does not respond to scene changes. The core issue here is that we're faking the eye's or camera's automatic aperture and exposure adjustment through the use of constant ambient light. So even in total darkness the craft is still visible for gameplay reasons. 

sadly unity does not come with any inbuilt tools to get light brightness at a particular point. A brute force implementation is to raycast to every light source that is affecting the scene, evaluate their strength through the distance obtained and add them together. this is a rather clunky approach to things and would likely not work too well.

The probably better approach would be to set up some kind of evaluation (maybe that is inbuilt in unity*) to get what the current camera's exposure should be depending on how bright the scene is lit by sun and other light sources compared to how bright it appears on screen. Then this parameter could be used to change how the plume looks. 

*If the high definition render pipeline is used there appears to be a setting for camera aperture in unity that can be accessed through scripts. source

----------------------------------------------------(post merge line)

 

in regards to an earlier discussion: Things like whether motion blur, bloom, etc should be active and how strong should be things that should absolutely be exposed to the user under an advanced menu. Unity provides a bunch of other post processing options too, all of which should in my opinion be accessible to the user to tune them however they wish. Their configs should also be saved in namable presets that are in individual files so they can easily be shared from user to user. 

[HB Stratos]

2 hours ago, Aaron VFX said:

I'll note your suggestions on plume modability. As always, no guarantees on what is exposed but it's a valid suggestion. Out of curiosity, what are the key elements you all would like control of? I'm thinking color, texture, a way to import your own mesh blends, etc. I don't have much experience setting up content for mod support, so knowing what is helpful will let me wrap my head around better ways to approach the possibilities. 

it really depends on what you want to do. Modders will somehow bodge a way in even if you don't provide one. But you can make it significantly easier. This can be through easily accessible modding API things, good documentation of said API, or even going as far as making a graphical in-game tool every somewhat knowledgeable player can use. The best compromise would probably be finding a way to publish your internal tools for creating these plumes. Like this a new editor doesn't have to be written and we get as much power as the devs themselves. 

Edited December 22, 2021 by HB Stratos

[HB Stratos]

Some beautiful shots showing off the heatblur on real planes, and also the reason why I really want the blur to be worldspace. Just look at these trails left behind the planes, it just looks so cool. And it is possible to tell if an engine is on even if one can't look at it from the back.

Some notes on the heat blur visible here:

• the blur behavior is interesting, expanding almost directly behind the engine then expanding way slower until it fades out way behind the plane.
• there's quite a lot of blurring and less distortion going on, presumably because of the velocity of the exhaust blurring things in camera.
• the interaction of the heatblur plume with the ground on pitch-up

One can also see low pressure vapor clouds above the wings of the F-16 in high g maneuvers, any chance that we will see something like that in KSP2? Also on a similar note, any chance of wingtip vortices like this:

First of all, more heatblur. Second of all, look at the wintip vortices forming, and their shadows on the ground. Such an interesting phenomena, though in ksp it brings the challenge of finding out where the wing tips are and when they should cause these vortices, given that a player can create a vessel of any shape and throw it at the physics simulation.

[rextable]

On 12/22/2021 at 7:46 PM, Aaron VFX said:

 

 

 

Edited December 29, 2021 by rextable

[DerkyJerkyWreaksHavoc]

On 9/17/2021 at 5:00 AM, Intercept Games said:

Hey! I’m Jon Cioletti, the technical artist on KSP2. As a tech artist, it is my job to help merge the work done by artists into the more technical side of the project, to assist artists by making tools, and to write shaders for our game assets.

The most satisfying challenge of my work is that everything we make is driven by scientific accuracy. Whether it’s the lighting or the VFX, we want to be able to point at something happening in game and have a real reason behind why it appears the way it does. One of the best features to showcase this is with our engine exhaust visual effects.

Now buckle up, because the rest of this blog will now be me trying to summarize the lengthy creative process for engine VFX into like a 7 min read. Wish me luck.

Setting our goals

Step one for any concept investigation work starts with looking at cool images for reference and trying to decide what you want out of a feature. Many conversations occur at the design / art level well before it even gets to me in the pipeline. It’s in this time that people like Nate Simpson, Aaron Lundquist, and Dr. Michael Dodd discuss what our goals are for the effect and what scientific requirements it has.

For example, a major driving factor in the exhaust for us is pressure regimes. Pressure regimes roughly fall into three categories: sea level, transitional, and vacuum. We can create mockups for each of these states, then blend between them to create a more realistic depiction of exhaust. From this we can break down other aspects of the exhaust (color, shock diamond, heat distortion) and track them throughout the change in pressure. As seen in Nate’s diagram below, we already have the shape language of our effect planned out early in the process.

 

The first in-engine preview

Once the initial conceptual investigation is complete, we move down the pipeline to the art and VFX investigation of the effect. It’s here that we take the concepts and visual reference and start reproducing it in engine.

Below is work by Aaron Lundquist to create some initial looks at exhaust using scrolling textures, alpha masking, some vertex displacement and a nice dash of bloom to get that great glow.

Here we can see how the combination of textures can create a stunning effect

And here it is in motion

Taking a look at the Tech!

VFX Throttle Manager

 

Most of our tech for the engine exhaust is driven by that engine’s throttle and the air pressure at a given location in the universe. As we increase our throttle the exhaust

elongates, shows signs of speeding up and glows brighter with the increase of heat. The location in the universe is responsible for our transitions through pressure regimes. As an engine moves through different spaces, the exhaust will distort and tint to differ colors. To pass this data we need a component on the engine object in game. This component will collect the proper exhaust data values and send it off to our meshes, and materials.

Script based mesh scaling

One part the Throttle Manager handles is the scaling of the exhaust’s shock diamonds. As the engine’s throttle increases, we scale the mesh for the diamonds larger and longer in accordance with the reference footage and diagrams we collected during our research phase.

Scaling of shock diamonds

 

BlendShapes

The Throttle Manager also controls the blending of our BlendShapes. To maintain our shape language established in the concept phases, we chose to work with BlendShapes, a technique used frequently in games for interpolating meshes. Below showcases some of that work in action thanks to renowned Kerbothropologist Paul Zimmer.

BlendShape models for blending BlendShapes blending based on throttle and pressure

Materials and Shaders

Simple hierarchy for models

The last thing our Throttle Manager passes data to is our effect’s material and shader. It’s here that we start modifying the actual look of the mesh itself so that it resembles something like the chemical reaction we see when an engine fires off. It’s also at this phase that we finally reach the place in the pipeline where I do my work on the effect.

“But Jon, what’s a shader?”

I’m glad you asked!

To boil it down to the bare essentials, a shader is a program that runs on the GPU that basically answers the question: “What color is this pixel when it is rendered to the screen?”. Like I mentioned above, it’s how we give things like the BlendShape and shock diamond meshes their exhaust look.

Breakdown of a vert/frag shader

Every 3D model that we want to see in game needs a Material. Each material contains both the shader and the values we pass to it to modify it’s look. By passing in different values to our shader, we can create a wide range of exhaust materials for our different exhaust types. It’s pretty powerful stuff.

On the inside a shader can also be broken down into a few major parts. On the top we have its properties. “What values from the shader do we want to expose to the artist or code to modify?”. Colors, textures, numbers, and vectors are all valid inputs. Next is the vertex function. This is the first pass the geometry faces and is responsible for the altering of the 3D model’s vertices. While the BlendShapes modify the general structure, the vertex function lets us add things like a rumbling offset. Once through, the mesh’s triangle data then heads to the fragment function to receive their final colors. It’s here where our lighting and final surface look is calculated.

 

 

Example of modifying the Material’s color to get a different exhaust look

All together now

Okay, now for the big diagram. Below shows the data flow mentioned at the start of this section. Here is the basic flow:

1. The engine part’s Throttle Manager collects the data it needs from the game and uses it to calculate the exhaust data that needs to be passed along to the 3D mesh and material

2. The exhaust data scales or blends the shock diamonds and BlendShapes

3. The exhaust data is passed to the shader’s properties

   1. Once in the shader it runs through the vertex function. The data modifies our exhaust’s shape to simulate turbulence and bends under acceleration

   2. Next passing through the fragment shader, it receives its color gradient tinting, a scrolling noise to break up the gradient, an erosion alpha mask at the tail end, fresnels to soften up the edges and exit traces

4. Once through this process, the render pipeline renders the final effect to screen. And that’s just a single frame!

Getting the tech into the artist’s hands

Hey you made it this far! Your reward is the same as ours after this process, some sweet engine exhaust effects. With all these tools in place we can let Aaron loose on creating some amazing exhaust effects. This only covers the exhaust itself, there are still additional lighting and particle effects that need to be added. Enjoy!

View the full article

OH... MY... GoODNesS... that... IS STUNNINGLY BEAUTIFUL!!!! WOW! AWESOME WORK!!!

and also im assuming the large engine being used in the examples is the "Mainsail" engine if im not mistaken...

Edited January 10, 2022 by DAFATRONALDO2007 IN SPACE
SUss...

[Brandon10044]

On 9/17/2021 at 5:00 AM, Intercept Games said:

Hey! I’m Jon Cioletti, the technical artist on KSP2. As a tech artist, it is my job to help merge the work done by artists into the more technical side of the project, to assist artists by making tools, and to write shaders for our game assets.

The most satisfying challenge of my work is that everything we make is driven by scientific accuracy. Whether it’s the lighting or the VFX, we want to be able to point at something happening in game and have a real reason behind why it appears the way it does. One of the best features to showcase this is with our engine exhaust visual effects.

Now buckle up, because the rest of this blog will now be me trying to summarize the lengthy creative process for engine VFX into like a 7 min read. Wish me luck.

Setting our goals

Step one for any concept investigation work starts with looking at cool images for reference and trying to decide what you want out of a feature. Many conversations occur at the design / art level well before it even gets to me in the pipeline. It’s in this time that people like Nate Simpson, Aaron Lundquist, and Dr. Michael Dodd discuss what our goals are for the effect and what scientific requirements it has.

For example, a major driving factor in the exhaust for us is pressure regimes. Pressure regimes roughly fall into three categories: sea level, transitional, and vacuum. We can create mockups for each of these states, then blend between them to create a more realistic depiction of exhaust. From this we can break down other aspects of the exhaust (color, shock diamond, heat distortion) and track them throughout the change in pressure. As seen in Nate’s diagram below, we already have the shape language of our effect planned out early in the process.

 

The first in-engine preview

Once the initial conceptual investigation is complete, we move down the pipeline to the art and VFX investigation of the effect. It’s here that we take the concepts and visual reference and start reproducing it in engine.

Below is work by Aaron Lundquist to create some initial looks at exhaust using scrolling textures, alpha masking, some vertex displacement and a nice dash of bloom to get that great glow.

Here we can see how the combination of textures can create a stunning effect

And here it is in motion

Taking a look at the Tech!

VFX Throttle Manager

 

Most of our tech for the engine exhaust is driven by that engine’s throttle and the air pressure at a given location in the universe. As we increase our throttle the exhaust

elongates, shows signs of speeding up and glows brighter with the increase of heat. The location in the universe is responsible for our transitions through pressure regimes. As an engine moves through different spaces, the exhaust will distort and tint to differ colors. To pass this data we need a component on the engine object in game. This component will collect the proper exhaust data values and send it off to our meshes, and materials.

Script based mesh scaling

One part the Throttle Manager handles is the scaling of the exhaust’s shock diamonds. As the engine’s throttle increases, we scale the mesh for the diamonds larger and longer in accordance with the reference footage and diagrams we collected during our research phase.

Scaling of shock diamonds

 

BlendShapes

The Throttle Manager also controls the blending of our BlendShapes. To maintain our shape language established in the concept phases, we chose to work with BlendShapes, a technique used frequently in games for interpolating meshes. Below showcases some of that work in action thanks to renowned Kerbothropologist Paul Zimmer.

BlendShape models for blending BlendShapes blending based on throttle and pressure

Materials and Shaders

Simple hierarchy for models

The last thing our Throttle Manager passes data to is our effect’s material and shader. It’s here that we start modifying the actual look of the mesh itself so that it resembles something like the chemical reaction we see when an engine fires off. It’s also at this phase that we finally reach the place in the pipeline where I do my work on the effect.

“But Jon, what’s a shader?”

I’m glad you asked!

To boil it down to the bare essentials, a shader is a program that runs on the GPU that basically answers the question: “What color is this pixel when it is rendered to the screen?”. Like I mentioned above, it’s how we give things like the BlendShape and shock diamond meshes their exhaust look.

Breakdown of a vert/frag shader

Every 3D model that we want to see in game needs a Material. Each material contains both the shader and the values we pass to it to modify it’s look. By passing in different values to our shader, we can create a wide range of exhaust materials for our different exhaust types. It’s pretty powerful stuff.

On the inside a shader can also be broken down into a few major parts. On the top we have its properties. “What values from the shader do we want to expose to the artist or code to modify?”. Colors, textures, numbers, and vectors are all valid inputs. Next is the vertex function. This is the first pass the geometry faces and is responsible for the altering of the 3D model’s vertices. While the BlendShapes modify the general structure, the vertex function lets us add things like a rumbling offset. Once through, the mesh’s triangle data then heads to the fragment function to receive their final colors. It’s here where our lighting and final surface look is calculated.

 

 

Example of modifying the Material’s color to get a different exhaust look

All together now

Okay, now for the big diagram. Below shows the data flow mentioned at the start of this section. Here is the basic flow:

1. The engine part’s Throttle Manager collects the data it needs from the game and uses it to calculate the exhaust data that needs to be passed along to the 3D mesh and material

2. The exhaust data scales or blends the shock diamonds and BlendShapes

3. The exhaust data is passed to the shader’s properties

   1. Once in the shader it runs through the vertex function. The data modifies our exhaust’s shape to simulate turbulence and bends under acceleration

   2. Next passing through the fragment shader, it receives its color gradient tinting, a scrolling noise to break up the gradient, an erosion alpha mask at the tail end, fresnels to soften up the edges and exit traces

4. Once through this process, the render pipeline renders the final effect to screen. And that’s just a single frame!

Getting the tech into the artist’s hands

Hey you made it this far! Your reward is the same as ours after this process, some sweet engine exhaust effects. With all these tools in place we can let Aaron loose on creating some amazing exhaust effects. This only covers the exhaust itself, there are still additional lighting and particle effects that need to be added. Enjoy!

View the full article

This all looks fantastic! I'm so excited for KSP 2, the work you are all putting into this game is incredible! Out of curiosity, for the KE-1 Engine, if it's included in KSP 2, will it have film cooling effect as seen IRL? Not to be rude.

[Pthigrivi]

Updated stance on camera shake after paying attention to it over the last few weeks: Its actually good, but it's like well designed stairs. When done well you don't even notice it. 

[ZDanimal]

Kudos on this one. I am sort of late to the party on KSP 1; I actually started playing just a few months ago but love it so far. One of my pet peeves on 1 is that the engine exhaust doesn't change with external pressure, but I can see that you're dealing with that in 2. Probably shouldn't show any kind of flame aside from the chamber once in vacuum. 

Edited January 17, 2022 by ZDanimal

[Gurkonier]

You can use the RealPlume Mod for this. I don't play KSP without it.
 

 

[Zorg]

Personally I recommend Waterfall (which is mesh based just like the stuff shown here) and use Realplume for SRB smoke. You can install both together.

[Gurkonier]

Looks nice. I'll give it a try.

[gussi111]

It seems that the game will look so incredible that for the first few hours I could only hover with my rocket above KSC and look at the plume or look at the sunsets to feel satisfied.  

[intelliCom]

On 1/28/2022 at 10:37 AM, gussi111 said:

It seems that the game will look so incredible that for the first few hours I could only hover with my rocket above KSC and look at the plume or look at the sunsets to feel satisfied.  

If Kerbin is detailed enough, one idea I had- before anything else- was to make a plane and just fly around Kerbin, get a feel for it. Use it as an opportunity to get used to any new bits that the game has.

When I finally feel ready, I'll perform a first actual launch.

[Bej Kerman]

On 12/14/2021 at 7:17 PM, Aaron VFX said:

Yea, I was just playing around with my comment. No motion blur. Only moderate camera shake where appropriate. While we're on visual flourishes that can opinionate people, what about bloom, heat refraction and lens flairs? What does the community think about these in general?

Make em options and you'll make everyone happy, make em mandatory (or don't do them at all) and you'll make at least one unhappy.

[MechBFP]

16 hours ago, Bej Kerman said:

Make em options and you'll make everyone happy, make em mandatory (or don't do them at all) and you'll make at least one unhappy.

I am guessing you don't remember the criticism regarding KSP having too many options?

[Ahres]

On 12/14/2021 at 12:31 PM, Aaron VFX said:

For you Ahres, I'll ask for a cameo in the next vid. 

Has the beard gotten so out of hand that they're not granting you any cameos?

[THE_KERBAL]

these are pretty good. looking forward to KSP2

[Jimbodiah]

So..... Real Plumes basically.

[Meredith Nathaniei]

It seems that KSP2 will still use the Unity engine as a game engine, I don't know if this is just using the KSP1 example as an explanation.

[Ashandalar]

24 minutes ago, Meredith Nathaniei said:

It seems that KSP2 will still use the Unity engine as a game engine, I don't know if this is just using the KSP1 example as an explanation.

We've known they are using Unity since 2019.

[Bej Kerman]

6 hours ago, Meredith Nathaniei said:

I don't know if this is just using the KSP1 example as an explanation.

This makes no sense to me. Please explain why the KSP 2 team would ever do this