New ReleaseD3D9Client Development

SolarLiner

It's necessary, TARS.
Depth information shouldn't have anything to do with how the glow is affected. Besides, if we attenuate based on the distance then there would be no glow anymore coming from the sun nor the atmosphere... which would defeat the very purpose of the shader.

Once HDR is there, there'll be a way to only apply bloom to truly bright sources. Now it's just a hack, and an experiment.
By the way, since it looks like this is evolving into a general post-processing shader, I suggest renaming the shader accordingly. Also adding a VertexShader function, too.

DaveS

Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Applying that effect/look into existing orbiter model, textures and material could be a challenge. It could require some color transforms for textures and materials which would result compatibility issues with the DX7. I guess we have little less freedom and flexibility than regular game developers. They don't have compatibility issues to worry about.
I think it might be worth posting a poll about the general feeling about compatibility with DX7. Last month I got a 27" Acer Predator IPS panel and since then the inline client refuses to work, even with the resolution at 1920x1080 like before. I think the inline client is on the ropes and it will just get worse. So getting as far away from it might be the better choice here.

So to me it makes no difference if D3D9Client breaks compatibility with the inline client.

Urwumpe

Not funny anymore
Donator
I agree there - DirectX 7 is already so long obsolete (DirectX 12 is already norm), that it could gently be phased out. DirectX 9 already feels like a good baseline.

On the blur issue - it is too artistic. It only makes sense in Orbiter if you would also reduce brightness for everything else away from the centerline of the camera, like you are directly watching at somebody walking towards you in front of bright spotlights.

Last edited:

SolarLiner

It's necessary, TARS.
I share the same feelings here. D3D9 is the only way I play Orbiter now. The last time I opened the inline one was by mistake, and it was a year ago (not counting opening the beta ones, because I did open them to check out the new terrain feature at the time). So whether or not D3D9 breaks compatibility isn't such a problem with me, the only thing it does is holding us back.

4throck

Enthusiast !
Same here. I think compatibility is not a problem. At worse an add-on creator may need to release a different texture set for the inline client.

marcogavazzeni

hello guys, I do not know if this problem is already present, the runway lights are more shallow than the strip that is more high than at sea level.
This only happens using D3D9.

In normal mode

With D3D9

If the problem was known,i m sorry.

SolarLiner

It's necessary, TARS.

I merged the two versions, one I had and the other from TestBuild5, as I realized jarmonik released it right before seeing I had made some changes. So here it is again!
BTW I made a whole album with nothing but Orbiter 2016 shots in 4k there: http://imgur.com/a/FlBFU

Changes to LightBlur.hlsl:
- Added the BufferDivider, PassCount and BufferFormat from jarmo's version
- Set up a "LUT Intensity" parameters that blends between original and color corrected image
- Added a vibrance pass which should help in reducing the "washed out" effect some were reporting (check the screenshots)

I think we can remove the falloff thing at the blending stage as it was doing the purpose of a "poor man's bright pass" effect. Also now that we can control the down-sampling of the blur buffer, it's even less costly to do large blurs, so thanks for that jarmo! :thumbup:

Attachments

• LightBlur.zip
1.7 KB · Views: 20

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Here is a new experimental set of shaders with HDR.

I have looked into the implementation of HDR and one problem is that a floating point backbuffer has no limitations in a dynamic range but the image still needs to be "composed" to a range form 0.0 to 1.0 before it can be visualized on a screen.

One solution could be a normalization of a color:

out_color = color / max(1, max(color.r, max(color.g, color.b)));

This has at-least following benefits:
- No changes required to current textures or materials
- Perfectly linear
- Any bright pixel going above 1.0 will retain it's original color. No color shift towards white.

An other HDR related issue is a brightness difference between white lambertian surface and metallic surface. In a literature a BRDF's are usually defined as F() = d/PI + s, where the diffuse term is divided by PI. For simplicity, I have multiplied the specular term by PI. Sun light intensity and specular multiplier can be defined from LightBlur.hlsl In the current implementation, Earth's atmospheric intensity does not go beyond 1.0 and no changes are being made there anytime soon.

So, is that actually fact ? White lambertian surface would reflect 1/PI less light than mirror to optimal direction ?

PHP:
// Other configurations ------------------------------------------------
//
#define fSunIntensity	1.0	// Sunlight intensity
#define fSunSpecular	3.14	// Specular multiplier

Also, the specular/reflection color has been changed from RGB to sRGB color space. It's approximately RGB = pow(sRGB, 2.2) however the current approximation pushes it little further down to RGB = pow(sRGB, 2.0) to reduce computation costs.

Based on how I have understood the concept of micro surface roughness, 1.0 = mirror smooth and 0.0 = lambertian surface (i.e. diffuse only). So, any roughness approaching to zero will also reduce specular/reflection color to zero. Also, Ward's BRDF doesn't work with very rough materials.

Martin mentioned a word "release candidate" in a beta thread and there is a new video published without "Beta" text in a splash screen. So, I guess it's better to start focusing building a stable release pretty soon. So, it's probably not a good idea to start pushing the HDR any further at this point. (i.e. beyond meshes and post processing)

I don't really like very large and complex shaders, so, it might be good idea to split the shaders to a basic shader (i.e. PBR.fx) and an advanced shader that would support more textures and features.

Rendering tasks for a basic PBR.fx:
* All non-textured objects
* Textured objects with
- Normal map (_norm)
- Roughness map (_rghn)
- Reflection map (_refl)
- Emission map (_emis)

- Specular map (_spec)
- Translucence map (_transl)
- Transmittance map (_transm)
- Anisotropic roughness map (_anis)

The next thing to do is to implement local light sources in a per pixel basis. This would likely mean that:
- Number of active light sources per scene could increase to 16 or 32
- Number of active light sources per mesh or mesh group would reduce down to 8 or 4 based on performance settings.

EDIT: Also, since the taste of post processing seems to wary, we could have a combo-box selector in a launchpad from where to change the effect. Which would allow to distribute multiple variants with the client.

.

Attachments

4.4 KB · Views: 13
Last edited:

SolarLiner

It's necessary, TARS.
Here is a new experimental set of shaders with HDR.

I have looked into the implementation of HDR and one problem is that a floating point backbuffer has no limitations in a dynamic range but the image still needs to be "composed" to a range form 0.0 to 1.0 before it can be visualized on a screen.

Ahh, tone-mapping. There are only so many algorithms that 'converts' HDR into LDR. Linearization is one thing, but I think a good way to do it is by emulating a photoreceptor to some extent.
Reinhard is almost an 'industry standard' when it comes to that, but many games do it differently. There simply is no answer to the question "How do I turn a HDR into LDR?" - or, well, the only valid answer could be "it's a matter of taste".

Personally, Reinhard tonemapping wouldn't hold here; with the beautiful scattering the Earth gets, colors would get washed out and the darker areas would lose contrast. Uncharted 2 had a solution to this problem by having a more tweakable tonemapping equation. (BTW, Hable John's slides on HDR Lighting here, it's a good read)

In fact, the Uncharted 2 technique is based on a filmic curve, because it mimics the response to film, and that looks real good. But, in order to make it truly working, we'd have to get local white points, that is, looking up the brightness value from an average of the brightness over a part of the image (as opposed to the whole image at once). This can be looked up using the Desaturate() function I used in the LightBlur effect, and sampled from a 2x2 or 4x4 mipmap of the backbuffer.

This will also serve as a "poor man's auto-exposure" before a real one is implemented, because I think it should be part of the post processing at this point.

In the current implementation, Earth's atmospheric intensity does not go beyond 1.0 and no changes are being made there anytime soon.
And that's a shame here because IIRC there is a HDR tonemapping pass to restrict to a [0,1] range on the atmospheric shader pass. In a way, we would only move the tonemapping pass to the post-process, and that would also allow for a better integration.

Also, the specular/reflection color has been changed from RGB to sRGB color space. It's approximately RGB = pow(sRGB, 2.2) however the current approximation pushes it little further down to RGB = pow(sRGB, 2.0) to reduce computation costs.

Based on how I have understood the concept of micro surface roughness, 1.0 = mirror smooth and 0.0 = lambertian surface (i.e. diffuse only). So, any roughness approaching to zero will also reduce specular/reflection color to zero. Also, Ward's BRDF doesn't work with very rough materials.

Martin mentioned a word "release candidate" in a beta thread and there is a new video published without "Beta" text in a splash screen. So, I guess it's better to start focusing building a stable release pretty soon. So, it's probably not a good idea to start pushing the HDR any further at this point. (i.e. beyond meshes and post processing)

I don't really like how we'd be stopping midway through here, but having HDR defined and a post-processing shader ready is I think enough to be destined for a stable release. Props on the work so far! :tiphat:

Rendering tasks for a basic PBR.fx:
* All non-textured objects
* Textured objects with
- Normal map (_norm)
- Roughness map (_rghn)
- Reflection map (_refl)
- Emission map (_emis)

- Specular map (_spec)
- Translucence map (_transl)
- Transmittance map (_transm)
- Anisotropic roughness map (_anis)
Specular maps and reflection maps are one and the same under PBR shading. More accurately, specular hardness is the smoothness (or the inverse of the roughness). Anisotropic roughness would be awesome to implement, and translucence/transmittance would be perfect for solar panels, though I think there's already something in place?

EDIT: Also, since the taste of post processing seems to wary, we could have a combo-box selector in a launchpad from where to change the effect. Which would allow to distribute multiple variants with the client.
I think it'd be better to expose the shader values directly, so one could control the bloom threshold and intensity, perhaps even in realtime if possible.

SolarLiner

It's necessary, TARS.
BTW I'm adding the star texture and sun config I've used for the last screenshots. I think they help a lot here.

I've naively applied the Uncharted tonemapping onto she shader, but there's no proper HDR for now, so it's basically useless at this point. Maybe with another test build?

Attachments

• Star.zip
992.4 KB · Views: 21
• 00029.jpg
43.7 KB · Views: 39

kuddel

Donator
Donator
A little something that "annoys" me is the stretching of Mother Earth in the splash screen while launching D3D9 scenarios.
It doesn't happen in plain Orbiter.

The two screens share the same background indeed:

In plain orbiter.exe there are 2 black bands at both sides.
These bands are "removed" in D3D9, hence causing the stretched look.

Please save Mother Earth from being squashed! :rofl:

Hi Ripley,
sorry your "request" was kind of overlooked while all folks are concentrating on "shiny light"
Please try the attached release (hopefully no new errors were introduced meanwhile).
This should "respect the earth proportions" better :lol:

/Kuddel

Last edited:

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Ahh, tone-mapping....

This can be looked up using the Desaturate() function I used in the LightBlur effect, and sampled from a 2x2 or 4x4 mipmap of the backbuffer.

Done. 4x4 mipmap is now available in "tTone".

In a way, we would only move the tonemapping pass to the post-process, and that would also allow for a better integration.

Done

Specular maps and reflection maps are one and the same under PBR shading.

True, and I am not going to do anything with specular. But it's kept just is case if someone want's to do some non-PBR stuff.

The CLUT texture is now 2D as requested earlier.

Attachments

• D3D9ClientBeta-TestBuild6.zip
1.7 MB · Views: 31

Eduard

New member
Hi Ripley,
sorry your "request" was kind of overlooked while all folks are concentrating on "shiny light"
Please try the attached release (hopefully no new errors were introduced meanwhile).
This should "respect the earth proportions" better :lol:

/Kuddel

I am experiencing a new problem with this latest build:
Orbiter does not terminate correctly with the "Respawn Orbiter-process" setting (that I always use, so I can be shure that everything is reloaded in the memory) or the "Terminate Orbiter-process" enabled.
When looking in the taskmanager, the process continues running and the Launchpad does not show up again.

The previous version I used was D3D9ClientBeta23.1-forBETA r55(r602).zip en now I am using this latest version D3D9ClientBeta23.3-forBETA r55(r628).zip.

Last edited:

Ripley

Tutorial translator
Donator
Hi Ripley,
sorry your "request" was kind of overlooked while all folks are concentrating on "shiny light"...
Hi, no problems!
MOAR SHINY LIGHTS!!!

Meanwhile, Earth looks better indeed, but black sidebands don't.
Every time you run a scenario those bands show anything from "snow" (like in the screenshot) to some random-garbled data from memory as some MFD's text/numbers and such.
I realize it's a "super-minor" issue, so you decide if it deserves more dev time.

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Setback

Looks like we are having a setback with local lights. I thought it might be good idea to reduce the number of active local lights a bit and implement them in a pixel shader to gain a proper light/material interaction. DeltaGlider runs fine but there is a pretty dramatic drop in a frame rate with ISS A to Z. :compbash2:

Vertex lights did not slow down that much a high poly model. Based on how it looks it shouldn't have that many pixels but pixel shader seems to have a great deal of effect on how it runs.

First screen shot with 4-pixel lights, second shot with current PBR.fx shader without local lights, third shot with minimal pixel shader with just a few basic features. Could it be possible that hardware can't run the pixel shaders efficiently when the model is build from a tiny triangles. Most of them are probably less than a pixel in size.

This kind of implementation for local light sources isn't a good idea. So, I guess we need to return back to vertex based approach. Deferred architecture is one option but hard to believe that it would come without a price. Some transparency and material issues would exists and I would expect issues with cloud layer and planetary rings when camera and vessel are on a different side. Hard to say at this point. :crystalball:

EDIT: I also tried SSAA from driver control center for MSAA replacement and the frame rate increased a few frames.
.

Attachments

• Basic.jpg
215.5 KB · Views: 41
• Lights.jpg
214.5 KB · Views: 43
• Minimal.jpg
211.8 KB · Views: 44
Last edited:

4throck

Enthusiast !
Tried testbuild6 and it looks fine. The atmosphere and terrain look right!

Concentrating on things that are not OK:
You can see the sun's glow through the terrain. This is not new, and related to not having the terrain (and self) shadows.
View attachment 14476
(that's the Yosemite campsite for all the StarTrek V fans out there :lol

I'd say better shadows are the main thing missing right now.
The fancy texturing support is good as it is, at least until add-ons start using it.

Last edited:

kuddel

Donator
Donator
Hi, no problems!
MOAR SHINY LIGHTS!!!

Meanwhile, Earth looks better indeed, but black sidebands don't.
Every time you run a scenario those bands show anything from "snow" (like in the screenshot) to some random-garbled data from memory as some MFD's text/numbers and such.
I realize it's a "super-minor" issue, so you decide if it deserves more dev time.

Thanks for the report,
though I haven't seen that "noise" (uninitialized area, I think) here,
I think I have to take a closer look into it. Hopefully I can reproduce this here...
By the way this "fix" wasn't that much for an effort.
The shutdown issue reported by Eduard might be more severe to look at first.

/Kuddel

kuddel

Donator
Donator
Hey Ripley,

could you please try this one? I've added filling the render area with black background first.
Note: No other changes done, so any shutdown-issue should still be there (or miraculously gone )
/Kuddel

Attachments

• D3D9Client_splashfix.zip
483.7 KB · Views: 9

SolarLiner

It's necessary, TARS.
TestBuild 6 works fine! :tiphat:

Though the two things to change now would be to boost the intensity of the sun light so it's brighter than the atmosphere; right now with the tonemapping the ships look dull and washed out compared to the atmosphere below. That should go for the star billboard texture as well. Now that we have a way higher dynamic range, we shouldn't be afraid to use it. Tonemapping and exposure adaptation will take care of displaying the scene under a [0,1] range.
EDIT: Actually, that should also go for all emissive materials as well. Exhausts and emissive particle systems also look washed but once properly lighted they'll shine back again.

Speaking of adapration, my idea of a local average kinda failed as the 4x4 mipmap wasn't behaving the way I expected; I'd have thought mipmapping would average the values, but there's some kind of weighting being done that emphasizes the center pixel from what I see, and that in turn gives weird results. So I resorted to a geometric mean but with the 4x4 mipmap and that weird emphasizing it's still behaving weirdly.
So my question is, would a 1x1 mipmap be an average of the whole image? If yes, then could you change that for it?

Attached is how it looks with a standard Reinhard tonemap. Vessels look kinda grayed out because of the aforementioned reasons. I do think that once the sun light intensity is boosted, color will return, and that is too, not including the LUT texture, which I'm going to redo now since tonemapping is enabled.

Attachments

• 0000.jpg
94.7 KB · Views: 60
• LightBlur.zip
2 KB · Views: 9
Last edited:

kuddel

Donator
Donator
D3D9Client 23.4 (for Orbiter BETA r55)

I am experiencing a new problem with this latest build:
Orbiter does not terminate correctly with the "Respawn Orbiter-process" setting (that I always use, so I can be shure that everything is reloaded in the memory) or the "Terminate Orbiter-process" enabled.
When looking in the taskmanager, the process continues running and the Launchpad does not show up again.

The previous version I used was D3D9ClientBeta23.1-forBETA r55(r602).zip en now I am using this latest version D3D9ClientBeta23.3-forBETA r55(r628).zip.
Thanks for the report Eduard,
attached is the current release that should fix the "Respawn" issue.
/Kuddel

Last edited: