Improved Exhaust Particle Systems

[MattR]

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):


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?

 

[N_Molson]

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.

General Question - Overexpanded exhaust plumes

Sorry for another thread, but I hope those will be useful to other people too... I'm trying to get a decent overexpanded exhaust plume for my rocket, the kind of effects you see when a launcher gets in upper atmosphere, where the pressure is very low : On that picture, the rocket is...

www.orbiter-forum.com

 

[DaveS]

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]

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]

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:


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:


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:


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.

 

[N_Molson]

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]

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]

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]

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.

 

[4throck]

Found this on the web, might be a start regarding the parameters needed for a realistic display.
It's 2D only but if it can be done in the browser I'm sure it can be done in Orbiter...

WebGL Fire Particle Demo

ethanhjennings.github.io

 

[DaveS]

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.

 

[MattR]

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.