New Release D3D9Client Development

[jarmonik]

Here's the video where those two screenshots were taken from. ET venting begins at 2:30. And as you can see, the plume doesn't hang around for very long.

Thanks about the video. I guess we could try to improve the particle effects so that high-rate exhaust would be wider and long duration exhausts would travel farther away from the source.

 

[jarmonik]

Tried new version.
1) I noticed when whole stack of rocket (first stage - "landed" status) is selected, it is OK, but selecting (with F3 )orbiter (attached to main stack, so status of vessel in scenario is "orbiting") it gets brighter (~ ambient ligthing increases).

I'll try to reproduce that with AMSO..

2) Is "metalness" shader applied to a whole mesh? Seems that all groups of mesh have to "share" it. There are meshes, where only part is metallic, but part is just white, etc, where only OLD PBR shader is more appropriate.

Metalness shader can do both, Metallic and non-metallic. It's the metalness map where it gets it's name: youtube: Metansess vs Specular

3) Was this sunrise improvement thing about surface sunrises\sunsets?

That was about fixing bug related to a sunlight color received by a vessel during sunset/-rise

 

[GLS]

That plume is huge compared to the size of the E.T. How long is that plume visible after the valve is close or it's out of gas. My best guess would be 5-15 seconds. Let's forget this for now and focus on the two other cases. Engine exhaust and aerodynamic condensation effect.

The plume lasts for a LONG time, as the gas doesn't just disappear after x seconds, and in a vaccum it just keeps growing as there is nothing "containing" it. How long it is visible pretty much depends only on the camera settings... I don't think there is a way to win this one, because it will never "look good" on every situation.

 

[N_Molson]

Again yes lets focus on limited goals first (engine exhausts and aerodynamic effects), stay positive and then take time to dig in more particular cases.

The behavior of overexpanded gases is a bit different, I raised the issue there :

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

Now yes strictly speaking it has to do with engine exhaust ; eventually we'll have to find a way to deal with it, but lets start with how things look in the (familiar) dense part of Earth atmosphere.

 

[DaveS]

Thanks about the video. I guess we could try to improve the particle effects so that high-rate exhaust would be wider and long duration exhausts would travel farther away from the source.

I think that can currently be done with the particle stream system in place. Something it can't do currently is the visibility part, that the plume is only really visible from certain light angles. That is what I what I want to see implemented, variable plume visibility.

 

[DaveS]

I think that can currently be done with the particle stream system in place. Something it can't do currently is the visibility part, that the plume is only really visible from certain light angles. That is what I what I want to see implemented, variable plume visibility.

After thinking about this some more, I think this could replace the standard 2D exhaust renderings that you get through AddExhaust(). It could even be made user option in the Advanced Options window. That way those who want the "traditional/classic" 2D appearance and those who want the more realistic and accurate appearance both get their wills fulfilled.

 

[Felix24]

Here's a new smoothness curve function to try out that adds a Fresnel effect calculated from smoothness. Starting with line 241 in Metalness.fx:

// original function: fSmth = clamp(pow(abs(fSmth), gMtrl.roughness.y) * gMtrl.roughness.x, 0.0005f, 0.9999f);
fSmth = pow(abs(fSmth), gMtrl.roughness.y) * gMtrl.roughness.x;
fSmth = clamp( fSmth + ((1.0f - fSmth) * pow(abs(1.0f - dCN),4.0f)) * pow(abs(fSmth),0.5f), 0.01f, 0.999f);

The third line provides the Fresnel effect. abs(1.0f - dCN) is raised to the 4th power because it gave a good-enough visual result. Fresnel is the most intense where dCN approaches zero, and not in a linear fashion.

This bit * pow(abs(fSmth),0.5f) prevents the Fresnel effect for materials with 0 smoothness. 0.5 as exponent worked good enough.

Question: What is the purpose of clamp()? Is it to avoid a divide-by-zero condition later on?

 

[jarmonik]

Here's a new smoothness curve function to try out that adds a Fresnel effect calculated from smoothness. Starting with line 241 in Metalness.fx:

// original function: fSmth = clamp(pow(abs(fSmth), gMtrl.roughness.y) * gMtrl.roughness.x, 0.0005f, 0.9999f);
fSmth = pow(abs(fSmth), gMtrl.roughness.y) * gMtrl.roughness.x;
fSmth = clamp( fSmth + ((1.0f - fSmth) * pow(abs(1.0f - dCN),4.0f)) * pow(abs(fSmth),0.5f), 0.01f, 0.999f);

The third line provides the Fresnel effect. abs(1.0f - dCN) is raised to the 4th power because it gave a good-enough visual result. Fresnel is the most intense where dCN approaches zero, and not in a linear fashion.

This bit * pow(abs(fSmth),0.5f) prevents the Fresnel effect for materials with 0 smoothness. 0.5 as exponent worked good enough.

Thanks about that, I have included the modification in the latest build and it's looks good.

Question: What is the purpose of clamp()? Is it to avoid a divide-by-zero condition later on?

Yes, exactly that. I have removed the clamp since it's no longer needed. There was an other div-by-zero issue with dCN that caused some white pixels and geometry clipping. Although, now with-out the clamp if the smoothness is set to 1.0 then the sun reflection will completely disappear at-least from the test Sphere. Not sure if that good or bad.

 

[jarmonik]

D3D9Client 4.16 is Out

This build fixes a number of bugs and issues from the shading. Irradiance fall-off is made smoother. Felix24's modified smoothness function is included.

 

[jarmonik]

I have been thinking about this "aerodynamic condensation effect" and I have pieced together half of the plan but still evaluation options on how to provide turbulence. Some sort of Fourier texture has crossed my mind having a frequency, phase and magnitude but it might be too complex.

But there is still one very well known problem "The Interface". So, how is the data passed to the renderer ? Should we have some kind of slider panel on a client side that could be used for creating the effect and test playing it ?

And what about the interface:
OrbiterAPI ?
gcCoreAPI ?'
LUA ?
Configuration file ?
Configuration file + LUA ?

 

[4throck]

A configuration file is the most accessible for everyone. API will reduce the number of testers and possible implementations.

But don't forget about weather in general... condensation depends on atmospheric parameters.
I don't mind some Kerbal like generic eye candy, but to get realistic effects you need to simulate weather ( fog, overcast sky, etc, etc).
You can default to KSC clear sky conditions, but what about Baikonour in the middle of the winter ? It's a complex issue.


( I worry a bit about adding many new functions while previous ones aren't fully implemented.
I'm thinking about the TerrainToolbox incompatibility for example (as far as I know it's not solved) )

 

[GLS]

I have been thinking about this "aerodynamic condensation effect" and I have pieced together half of the plan but still evaluation options on how to provide turbulence. Some sort of Fourier texture has crossed my mind having a frequency, phase and magnitude but it might be too complex.

I think the visible turbulence is just the vehicle flying thru air with different ppH2O, which makes the amount of condensation change. Couldn't this be handled by the texture as it slides?

But there is still one very well known problem "The Interface". So, how is the data passed to the renderer ? Should we have some kind of slider panel on a client side that could be used for creating the effect and test playing it ?

And what about the interface:
OrbiterAPI ?
gcCoreAPI ?'
LUA ?
Configuration file ?
Configuration file + LUA ?

OrbiterAPI || vessel config file || LUA

But don't forget about weather in general... condensation depends on atmospheric parameters.

IMO this could be handled by making the effect random, with a 10-25% chance of happening.

 

[N_Molson]

And what about the interface:

I'm for OrbiterAPI. From there, someone can make a "Aero FX module" that handles it and then uses .cfg files.

 

[Felix24]

For exhaust streams, would it be possible to animate the exhaust by these methods?

• creating an animation texture with animation "frames" defined in a grid and cycling through the frames
• creating a single texture that animates by scrolling from top to bottom

And then applying either of those methods to a 2-d billboard texture, or to the surface of a 3-d plume extending out behind the nozzle.

 

[jarmonik]

For exhaust streams, would it be possible to animate the exhaust by these methods?

• creating an animation texture with animation "frames" defined in a grid and cycling through the frames
• creating a single texture that animates by scrolling from top to bottom

And then applying either of those methods to a 2-d billboard texture, or to the surface of a 3-d plume extending out behind the nozzle.

The idea of scrolling texture was briefly discussed a few posts ago. In engine exhausts and "condensation" effect it could bring some small details giving a better impression of movement or flow. This kind of texture alone would probably not work, somekind of mask would be required like a texture or a mesh. In a re-entry effects it could play a major part. So, Yes it would be possible.

I haven't really considered an animation grid. But, Yes it would be possible. I suppose this could enable the exhaust to change it's color after engine start by blending from one texture to an other. Also, if there are utilities those could be used to create an exhaust particle effect and then record it as an animation. That would be interesting

 

[GLS]

About engine plumes, the cylinder solution might look good from the side, but what about from the bottom?

 

[N_Molson]

About engine plumes, the cylinder solution might look good from the side, but what about from the bottom?

Does transparency takes mesh volume into account ? Meaning that a thick mesh should be less transparent than a thin one... Is it possible to achieve that ? Because I have the feeling it is quite critical to render a decent exhaust plume.

And thanks for the 4.16, works like a charm there.

 

[kuddel]

About engine plumes, the cylinder solution might look good from the side, but what about from the bottom?

You should not look directly into a burning rocket-engine ?
But seriously: A stack of several cylinders (with flat colored bottom faces) could provide a solution. The shock-diamond cones would be visible through those faces.
But enhancing the "big outer" cylinder by changing its shape at one end might be beneficial - that sketch was just one idea; improvements welcome

 

[jedidia]

One thing about the new metalness shader I'm noticing is that if I'm using a normal map, some parts can become transparent from certain angles...

 

[DaveS]

One thing about the new metalness shader I'm noticing is that if I'm using a normal map, some parts can become transparent from certain angles...

An issue I reported in this post: https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-578528