New Release D3D9Client Development

[Cras]

Orbiter 2010p1 with D3D9 R16.4

Trying to load up Pursuit MFD in the Arrow's VC crashes the sim. Havent tested all my MFDs yet to see which ones crash it, but this one does. I can load it up in the glass pit screen, but the second I go to the VC it crashes. The second I click on Pursuit from the MFD menu in the VC the sim crashes.

 

[jarmonik]

Specular map. This should have the reflection intensity + reflection color. We already have a specular texture, so nothing new here.

We already have a Reflection map containing the reflection color. Although, I don't quite understand what's the point of having specular color and separate reflection color. Since the material shouldn't care whether the light comes from the sun or from the environment.

Roughness map. This controls reflection, from mirror like to something more diffuse. It's connected to the surface roughness. For a solar panel, you will have brighter (smother) parts over the solar cells, and darker parts over the metal structure, wires, etc.
This is the only new texture.

What's the difference between roughness and specular power. Doesn't they specify the same thing in slightly different way ? We already have specular power stored in alpha channel of specular map. 0=rough, 1=glossy. Although, this only effects to the sunlight due to separate reflection map.

If a use of alpha channel is problematic then it would be possible to re-purpose the Reflection map as Roughness map and use a specular color for reflection too.

 

[4throck]

jarmonik, I'm only mentioning the texturing you will find on modern models or game engines.
I too find it a bit confusing, but that the current shaders support.

Roughness: you can have a shine surface (with specular) that's not polished (ex: Brushed metal) on that case you should see a blurred reflection.
Here's an example from http://artisaverb.info/PBT.html :

Having specific channels for Orbiter may complicate things, specially if it breaks conventions.
I personally hate messing with alpha channels, since each program handles them differently.
The current convention seems to be texture_A for albedo, texture_M for specular, texture_R for roughness and texture_N for normal.
Close to D3D9 standard ;-)



To make things clearer, here's a nice example of PBR texturing and the end result:

Result

Albedo:

Specular:

Roughness:

Normal:

Hope this makes it clearer.


For a more on topic example, look at this model from NASA:
http://nasa3d.arc.nasa.gov/detail/nmss-sev
It has bump, color, reflect, spec and spec_color textures ;-)

 

[Anroalh12]

What do you think is the best font rendering?

 

[SolarLiner]

We already have a Reflection map containing the reflection color. Although, I don't quite understand what's the point of having specular color and separate reflection color. Since the material shouldn't care whether the light comes from the sun or from the environment.

What's the difference between roughness and specular power. Doesn't they specify the same thing in slightly different way ? We already have specular power stored in alpha channel of specular map. 0=rough, 1=glossy. Although, this only effects to the sunlight due to separate reflection map.

Inherently they're the same. Looking at is from a CGI perspective, there is only diffuse and specular reflection (specular being the 'mirror type' reflection). They are two separate concepts in real time graphics because they aren't computed the same way and aren't looking to give the same result, but in real life the 'specular ripples' are a byproduct of the 'mirror-like' reflection of light. So in the end, the specular color will influence the reflection color.

 

[jarmonik]

For example, here's my Skylab B with PBR textures. It's the same model (and base textures) as in Orbiter.
https://sketchfab.com/models/eda477f1c1214a1f801eefea5da9bcee

I found the model from Orbit Hangar but do you happen to have the other textures for it. Roughness and Specular ?

 

[Ripley]

Latest Orbiter 2016 (revision 54, just checked out in a fresh folder) with D3D9 23 give me an error.
Plain Orbiter.exe runs with no problems.

Here's the error:

**** Orbiter.log
000000.000: Build Apr  2 2016 [v.160402]
000000.000: Timer precision: 4.16663e-010 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 150906, API 150906]
000000.000: Module AtmConfig.dll ......... [Build 150906, API 150906]
000000.000: Module DGConfigurator.dll .... [Build 150906, API 150906]
000000.000: Module D3D9Client.dll ........ [Build 160403, API 160402]
000000.000: 
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: 3D-Adapter = AMD Radeon HD 4800 Series
000000.000: D3D9: MaxTextureWidth........: 8192
000000.000: D3D9: MaxTextureHeight.......: 8192
000000.000: D3D9: MaxTextureRepeat.......: 8192
000000.000: D3D9: VolTexAddressCaps......: 0x3F
000000.000: D3D9: NumSimultaneousRTs.....: 4
000000.000: D3D9: VertexDeclCaps.........: 0x3FF
000000.000: D3D9: XNA Math Support.......: Yes
000000.000: D3D9: Vertex Texture.........: Yes
000000.000: D3D9: Shadow Mapping.........: Yes
000000.000: D3D9: D3DFMT_A16B16G16R16F...: Yes
000000.000: D3D9: D3DFMT_A32B32G32R32F...: Yes
000000.000: D3D9: D3DFMT_D32F_LOCKABLE...: Yes
000000.000: D3D9: D3DFMT_A2R10G10B10.....: Yes
000000.000: D3D9: D3DDTCAPS_DEC3N........: Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_2....: Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_4....: Yes
000000.000: D3D9: Available Texture Memory = 1075 MB
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: [Loading Constellations]
000000.000: D3D9: [D3D9Client Initialized]
000000.000: Module Sun.dll ............... [Build 150906, API 150906]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 150906, API 150906]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 150906, API 150906]
000000.000: Module VenusAtm2006.dll ...... [Build 150906, API 150906]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 150906, API 150906]
000000.000: Module EarthAtmJ71G.dll ...... [Build 150906, API 150906]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 150906, API 150906]
ELP82: Precision 1e-005, Terms 116/829
000000.000: Module Mars.dll .............. [Build 150906, API 150906]
000000.000: Module MarsAtm2006.dll ....... [Build 150906, API 150906]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 150906, API 150906]
000000.000: Module Jupiter.dll ........... [Build 150906, API 150906]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 150906, API 150906]
000000.000: Module Europa.dll ............ [Build 150906, API 150906]
000000.000: Module Ganymede.dll .......... [Build 150906, API 150906]
000000.000: Module Callisto.dll .......... [Build 150906, API 150906]
000000.000: Module Satsat.dll ............ [Build 150906, API 150906]
000000.000: Module Saturn.dll ............ [Build 150906, API 150906]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 150906, API 150906]
SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 150906, API 150906]
SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 150906, API 150906]
SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 150906, API 150906]
SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 150906, API 150906]
SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 150906, API 150906]
SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 150906, API 150906]
SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 150906, API 150906]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 150906, API 150906]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module Atlantis_SRB.dll ...... [Build 160323, API 160323]
000000.000: Module Atlantis_Tank.dll ..... [Build 160323, API 160323]
000000.000: Module Atlantis.dll .......... [Build 160402, API 160402]
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: VESSEL::CreateVariableDragElement
000000.000: At least one active module is accessing an obsolete interface function.
000000.000: Addons which rely on obsolete functions may not be compatible with
000000.000: future versions of Orbiter.
000000.000: ---------------------------------------------------------------
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: Module LuaInline.dll ......... [Build 160402, API 160402]

 

[Felix24]

We already have a Reflection map containing the reflection color. Although, I don't quite understand what's the point of having specular color and separate reflection color. Since the material shouldn't care whether the light comes from the sun or from the environment.

Reflection color and specular color are nice to keep separate because it allows surfaces to have a white gloss finish while also having a colored metallic sheen underneath. If you look at any car with metallic paint, the clear coat reflects white, while the underlying metallic paint reflects whatever color the paint is.

In the current shaders, conservation of energy is followed with relation to reflection light vs. diffused light. Increase the reflection value and the diffuse color darkens accordingly. Specular reflections in the shader are not forced to follow conservation of energy, because this allows specular reflections to create a "flare" of oversaturation. This effect is closer to real-world glare effects coming from high-intensity light sources like the sun.

---------- Post added at 03:42 AM ---------- Previous post was at 03:14 AM ----------

The reason why a deferred pipeline is considered is mostly SSAO (Screen Space Ambient Occlusion) which is the only dynamic AO technique implementable to the client.

SSAO is great for highly detailed 3d models, and models which are heavily animated, and are static and don't already have pre-made ambient occlusion maps. SSAO makes certain types of games look good, mainly games where the environment is in-atmosphere, with ambient light coming from every direction.

I don't think SSAO would benefit Orbiter very much. Most scenes in Orbiter are in space with light coming from very few directions at once. Granted, you can fly through an atmosphere, but that's not the main focus of the simulator. Also, most models in Orbiter are mostly made of big, smooth surfaces without a lot of detail and not heavily animated. A lot of SSAO demos on YouTube use highly detailed 3D statues as test subjects, or some complicated animation to demonstrate the effect calculated in realtime.

That being said, adding SSAO wouldn't really hurt things. Glare effects would be nice, though.

If shadowing is limited to self-shadows only not to vessel-on-vessel shadows, then it might get simpler.

Vessel-on-vessel shadows would be one of the things that would make flying around the ISS a lot more fun.

 

[Abloheet]

Ok, new lighting effects are very much welcome, SolarLiner's project ReShade for example. The only shame in it being that it reduces performance too much.

But what about implementing the rest of the effects and objects of the orbiter core, like trains, monorails, beacon arrays, solar panels?

 

[4throck]

I don't think SSAO would benefit Orbiter very much. Most scenes in Orbiter are in space with light coming from very few directions at once.

Cockpits can have multiple light sources. Look at the DG on the Beta, it features interior lights. They are static, yes, but the Sun is not, and it comes through the windows.
It benefits Kerbal, so it can't hurt Orbiter :thumbup:

 

[4throck]

I found the model from Orbit Hangar but do you happen to have the other textures for it. Roughness and Specular ?

For the panels I did the extra textures. For the other parts of the model I reused the same textures .

Here's a reduced jpg version (faster than sharing 2048*2048 pngs):
View attachment 14402

View attachment 14403

View attachment 14404

View attachment 14405

View attachment 14406

View attachment 14407

View attachment 14408

View attachment 14409


As you can see, the _spec map is the same as the albedo for panel1, but there are small differences for panel2.
That's why I think this is backward compatible. If not supplied, you can use the standard texture for albedo and specular...
The roughness map is the only really new thing.

Perhaps we should move this discussion to another thread, since it's moving away from the current D3D9.

 

[jarmonik]

For the panels I did the extra textures. For the other parts of the model I reused the same textures .

Here's a reduced jpg version (faster than sharing 2048*2048 pngs):

As you can see, the _spec map is the same as the albedo for panel1, but there are small differences for panel2.
That's why I think this is backward compatible. If not supplied, you can use the standard texture for albedo and specular...
The roughness map is the only really new thing.

Perhaps we should move this discussion to another thread, since it's moving away from the current D3D9.

Ok, Thanks. I'll try to get the roughness map to work. I need to create a blurred version of the environment map but there is small problem, it can't be blurred in a per material basis. So, I guess the implementation would be limited to two or three different env maps with different levels of blur effect applied to them.

 

[kuddel]

D3D9Client for Orbiter BETA r54

Latest Orbiter 2016 (revision 54, just checked out in a fresh folder) with D3D9 23 give me an error.
Plain Orbiter.exe runs with no problems.

Although I can't make out every detail of the Italian window...
...you could try the attached build of D3D9Client.
Maybe it fixes your problem.

 

[Ripley]

...Maybe it fixes your problem.

Thanks Kuddel, but no, it doesn't.

Since I probably am the last Orbinaut running on XP, I don't want you to devolve D3D9's development time "wasting" it on my (or few else's people) doomed jurassic pc (hopefully I'll be building a new rig soon).

Meanwhile, I can revert to the 22 version of the client, wich was running well, along with your fix from post #3634 (in Orbiter 2016 revision 53).



Edit: wrong assumption. Client version 22 + fix doesn't work anymore. Go figure. Maybe it's because of the new Orbiter revision?

 

[Felix24]

Cockpits can have multiple light sources. Look at the DG on the Beta, it features interior lights. They are static, yes, but the Sun is not, and it comes through the windows.
It benefits Kerbal, so it can't hurt Orbiter :thumbup:

The higher detail of virtual cockpits might benefit from SSAO. But point light sources like cockpit lights and the sun are directional and not ambient; occlusion of directional light is just a hard shadow. If SSAO can also do hard shadows and therefore take into account both ambient and directional light, then it holds more promise.

Does screen-space mean it is not truly geometry-based and therefore is the same no matter the lighting environment?

I'm interested in seeing some before/after pictures of SSAO in Kerbal.

If shadowing is limited to self-shadows only not to vessel-on-vessel shadows, then it might get simpler.

The ISS A to Z addon is made of multiple vessels all linked together. Vessel-on-vessel shadows would be the only ones that work in that case.

 

[Cras]

Getting some weirdness with Hud drawing in R16.4 / 2010p1

Didnt see this back in R12 but it seems tied to how RVOrientation displays the yellow boxes

 

[Enjo]

Hi Cras,

Do you experience a similar behavior with Launch MFD's HUD drawing?

 

[fort]

Since I probably am the last Orbinaut running on XP

https://www.youtube.com/watch?v=pAyKJAtDNCw

:tiphat:

 

[jarmonik]

Getting some weirdness with Hud drawing in R16.4 / 2010p1
Didnt see this back in R12 but it seems tied to how RVOrientation displays the yellow boxes

Does this fix the problem ?

 

[SolarLiner]

Ok, new lighting effects are very much welcome, SolarLiner's project ReShade for example. The only shame in it being that it reduces performance too much.

One way to greatly improve ReShade's performance is by disabling SSAO; you can do so by opening "Modules/Server/ReShade/McFX.cfg", searching for the line that start with "#define USE_AMBIENTOCCLUSION" and replacing the 1 with a 0

Cockpits can have multiple light sources. Look at the DG on the Beta, it features interior lights. They are static, yes, but the Sun is not, and it comes through the windows.
It benefits Kerbal, so it can't hurt Orbiter :thumbup:

Interior lights can be 'baked' onto the textures, which is what I did in this addon for the old DG: [ame="http://www.orbithangar.com/searchid.php?ID=5801"]DG Textures Enhancement[/ame]