Improved Exhaust Particle Systems

MattR

Active member
Joined
Aug 5, 2021
Messages
42
Reaction score
124
Points
33
Location
Melbourne
I'd like to modify orbiter's exhaust particle systems to allow external graphics clients to render more realistic exhaust effects.

Currently, vehicles exhausts in orbiter are typically defined by two separate volumes: one for fire, and one for contrail (the cloudy vapor trail that looks like smoke). I think the existing approach is suboptimal because in real-life the exhaust gasses are one continuous volume, with the visual difference between fire and contrail being largely driven by the temperature of the particles within the volume. In modern VFX rendering, both fire and vapor/smoke are are typically modeled as a single volume or particle system, and the voxels/particles are tagged with temperate data which evolves over time. The renderer uses this temperature data to lookup a blackbody radiation curve to calculate the amount of light emitted by that voxel/particle.

Here's a screenshot from the Skybolt graphics client (left and middle) using orbiter's current approach of separate fire and contrail particle systems, vs a photo of the real Shuttle (right):
OrbiterVsRealLifeShuttleExhaust.jpg

As you can see, the result is unrealistic because:
  1. The contrail occludes the fire. We could work around this by fading in the contrail with distance, however then we would lose a considerable amount of fire volume, since the underlying fire volume shape is far smaller than the contrail shape. It's also inefficient to render two overlapping systems for what could be more realistically represented as one system.
  2. The contrail begins at far too low a temperature. In the real photo we see a continuum of particles of exhaust gasses at varying temperatures. Potentially we could just treat the start of the contrail system as fire, however this would then make the existing fire system redundant, and orbiter provides no way to know how 'hot' a particular system should be.

To achieve a more realistic result like the image on the right, I'd like to see Orbiter's particle systems improved by:
  1. Replace the two particle systems with one particle system tuned to produce an exhaust shape that includes both the fire and contrail regions.
  2. Provide additional metadata for each particle system to allow graphics clients to know about the fire parts of the particle system. I suggest this would be best achieved with new properties for 'emission temperature' and 'heat transfer coefficient' (how quickly the particles cool down over time)
A potential consequence of these changes is it would require the existing renderers to be modified to preserve the existing appearance. Potentially we could maintain backwards compatibility by considering the existing particle systems as v1 and introducing a new v2 interface (e.g PARTICLESTREAMSPEC_V2) containing the new properties and unified particle system.

What do people think of this proposal?
 
Last edited:

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
I'd say it is a lighting problem. The exhaust plasma emits a lot of light, and in reality it seems to illuminate the smoke column "from the inside". Also in the current state of thing there are no "two particle systems". There is one that has two main submodes : EMISSIVE and DIFFUSE. The problem is that "EMISSIVE" doesn't actually emit light, it is only a "luminescent" texture, and that "DIFFUSE" doesn't really interact with local light sources (or not in a very realistic way).

I wrote something about those exhaust streams last year, I do think they need an overhaul.

 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
It also needs to be able to handle exhausts in a vacuum. The current implementation doesn't quite manage it.

Here's two videos showing two types of gases in a vacuum:
Gaseous hydrogen:

Mono-methyl Hydrazine/Dinitrogen tetroxide:
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
Is there a way we could add this as a "ticket" or a "request" in the OpenOrbiter development thing ? I still don't really understand how stuff like Github works (and I still don't resign but it will take some time), but I guess it would make sense. Maybe not top priority stuff, but still relatively important if we want Orbiter to remain up-to-date.

Also, one of the "flaws" of the current particle system is that it relies entirely on 2D sprites... Again my knowledge in 3D graphics is limited, so would it be realistic to give volume to those particle streams ? Don't they do that in other simulators with stuff such as "volumetric clouds" ? Again just a dumb question I really have no clue. ☁️
 

MattR

Active member
Joined
Aug 5, 2021
Messages
42
Reaction score
124
Points
33
Location
Melbourne
The exhaust plasma emits a lot of light, and in reality it seems to illuminate the smoke column "from the inside".
My impression is that the gasses are so hot near the nozzle they they are emitting light. At the top it's not so much a matter of illuminating a vapor column, rather the column is so hot that it is emissive. There is some indirect light effect of the plasma lighting the vapor, however I think this is a secondary effect, and with the right model we could get close to replicating the real-world reference without needing to calculate the indirect lighting.

Also in the current state of thing there are no "two particle systems".
Here are the two particle systems (perhaps I should have said 'streams') I'm referring to, this example is for the shuttle in Vessel/Atlantis/Common.cpp:
AtlantisParticleSystems.png

From a modeling point of view they are independent in that they have different growth rates, velocity variation, alpha function etc, and do not interact at all.

The two streams are shaped like this:
OrbiterExhaustParticles.png

In reality there are not two binary categories: flame/plasma and contrail. Instead it's a spectrum largely influenced by thermal gradient. I think it would be better to model the particle system as a singular system with emissivity that varies with particle age this:

OrbiterExhaustParticles-new.png
This approach is simpler since we only need to define one stream, it's more efficient since there's less overdraw, and it provides the renderer with enough information to replicate the real-life reference in a variety of situations by changing the way the particle properties evolve with time.
 

Attachments

  • 1653839230991.png
    1653839230991.png
    84.2 KB · Views: 0

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
And as @DaveS and I wrote above, we should keep in mind that this model only really works inside the densest layers of the atmosphere.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Particle systems could use a huge overhaul. Our's are still pretty Win98 if you ask me. A couple of things to keep in mind though:

  • Make it graphics client independent ( by placing the burdon of implementing a feature on the client)
  • Particle streams are a visual effect, simulating physics should be done by an addon or addon API.
  • But you could implement a complex and customizable stream system and demonstrate it simulating physics as an API demo.
  • Are systems other than particles better/more future proof?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Particle systems could use a huge overhaul. Our's are still pretty Win98 if you ask me.
And it is not only the particle systems that is that way but the standard 2D exhausts as well. Currently there's no way to get a true 3D exhaust rendered like that of the RL-10/RS-25/J-2 which are hydrolox engines that use regenerative nozzle cooling. Having a regenerative cooled engine means that the cold fuel (their cases, hydrogen) is actively circulated through the nozzle during operation which leads to clean, clear looking exhaust where the mach diamonds and shock waves are easily visible.

One contrast to this is the RS-25's "sister-engine", the RS-68 which also is a hydrolox engine, but it uses an ablative nozzle that burns a heat shielding material to cool it. This leads the distinctive red colored exhaust that you see on Delta IV Heavy launches, on the Medium+ vehicles, the SRM exhaust hid the RS-68 exhaust.
 

MattR

Active member
Joined
Aug 5, 2021
Messages
42
Reaction score
124
Points
33
Location
Melbourne
Is there a way we could add this as a "ticket" or a "request" in the OpenOrbiter development thing ? I still don't really understand how stuff like Github works (and I still don't resign but it will take some time), but I guess it would make sense. Maybe not top priority stuff, but still relatively important if we want Orbiter to remain up-to-date.

Also, one of the "flaws" of the current particle system is that it relies entirely on 2D sprites... Again my knowledge in 3D graphics is limited, so would it be realistic to give volume to those particle streams ? Don't they do that in other simulators with stuff such as "volumetric clouds" ? Again just a dumb question I really have no clue.
Yes you can raise it as an issue in Github, but for it to get implemented a developer needs to pick up the task and work on it, then raise a pull request to get it merged. I'm hoping to do a first pass improvement addressing some low hanging fruit, without requiring a big redesign.

With modern shaders it's possible to give each 2D sprite some 'transmission depth' and normal information (i.e as additional texture maps) which can be used to render them volumetrically. The transmission depths can be realistically integrated using beer's law etc similar to volumetric clouds. The normals are useful to fake shadowing in dense volumes, i.e particles are darker on the side away from the light. It's also possible to render deep shadow-maps of the particles to get very realistic shadowing.
Particle systems could use a huge overhaul. Our's are still pretty Win98 if you ask me. A couple of things to keep in mind though:

  • Make it graphics client independent ( by placing the burdon of implementing a feature on the client)
I'd like to see it made graphics client independent as well. The biggest problem with the current particles API is orbiter does not tell the client any contextual information about the particle system, like what type of gas it is, how hot it is, what kind of source the particles came from (solid rocket motor, air vent, air breathing engine etc). Without this contextual information there's no way for the client to do different effects for a cool air vent vs a plasma engine.

I think the first step for the overhaul is to add a particle spec V2 interface that includes contexual metadata. That way the clients can chose to render the effects however they like. I'd be happy to do a first pass of this implementation.

  • Are systems other than particles better/more future proof?
The two most popular modern options for representing these kind of effects are 1) particles and 2) 3D grids. One is not necessarily more modern or future-proof than the other, and there are pros and cons to each:
  • From a modeling perspective, particles are very memory efficient and faster to physically simulate. Grids are generally less memory efficient because they tend to have wasted space and are generally more complex and CPU intensive to simulate (navier stokes equations etc).
  • From a rendering perspective, grids are a more natural fit for volumetric rendering with ray-marching. Particles are a bit more complex to render volumetrically, but it's still very doable, for example by rasterizing all the particles into a buffer and doing scattering/lighting equations on the buffer.
I'd suggest sticking with particles for now. With my suggested V2 interface idea, Orbiter should provide the client with enough contextual information to use either technique as needed, or fallback on the stock particles approach for older clients.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
My impression is that the gasses are so hot near the nozzle they they are emitting light. At the top it's not so much a matter of illuminating a vapor column, rather the column is so hot that it is emissive. There is some indirect light effect of the plasma lighting the vapor, however I think this is a secondary effect, and with the right model we could get close to replicating the real-world reference without needing to calculate the indirect lighting.


Here are the two particle systems (perhaps I should have said 'streams') I'm referring to, this example is for the shuttle in Vessel/Atlantis/Common.cpp:
View attachment 28838

From a modeling point of view they are independent in that they have different growth rates, velocity variation, alpha function etc, and do not interact at all.

The two streams are shaped like this:
View attachment 28839

In reality there are not two binary categories: flame/plasma and contrail. Instead it's a spectrum largely influenced by thermal gradient. I think it would be better to model the particle system as a singular system with emissivity that varies with particle age this:

View attachment 28840
This approach is simpler since we only need to define one stream, it's more efficient since there's less overdraw, and it provides the renderer with enough information to replicate the real-life reference in a variety of situations by changing the way the particle properties evolve with time.
I have attached a photo from the launch of STS-41D (August 30 1984, 8:41:50 am EDT) that shows the SRB flame pillar structure quite nicely in a low exposure setting.
 

Attachments

  • STS41D-181-NOID-8.30.84.JPG
    STS41D-181-NOID-8.30.84.JPG
    12 KB · Views: 21

MattR

Active member
Joined
Aug 5, 2021
Messages
42
Reaction score
124
Points
33
Location
Melbourne
I have attached a photo from the launch of STS-41D (August 30 1984, 8:41:50 am EDT) that shows the SRB flame pillar structure quite nicely in a low exposure setting.
Thank you, that is an excellent reference photo.
 
Top