New Release D3D9Client Development

[kuddel]

@Jarmo: Could you take a look at issue found by Nikogori?
Scenario for easy check attached

 

[GLS]

I found a strange blue dome on Deimos using Beta r54 and D3D9Client. I put a DG in it but nothing happened...:lol: It can't be seen with default inline client.
View attachment 14394

Yeah, looks like NASA forgot to remove the alien structures from the elevation data :shifty:.

 

[DaveS]

I know very little at all about 3D rendering, but after some research, it seems the main benefit of deferred rendering would be inexpensive multiple light sources. I assume D3D9 currently uses a forward rendering approach.

It seems that ordinary deferred rendering has problems with multiple material types within a scene, whereas light-prepass rendering doesn't. Would this be a problem for scenes containing multiple vessels having parts with different material definitions?

Currently the only light sources in Orbiter I can think of are the sun, planet, and vessel lights. Could new visual effects be realized if a few hundred light sources were available?

Three major visual effects I'm hoping for in future versions are self-shadowing, realtime irradiance mapping (sunlight reflected off clouds, ocean sunglint, and land, also glow from planet night lights), and blurred reflections (a cross between mirror reflections and specular lighting, like reflections from smooth but not shiny metallic surfaces). Would using deferred or light-prepass architecture make any of these effects easier to realize?

A while back I found an article about realtime calculation of irradiance environment maps. I thought I linked to it in a D3D9 related thread, but I can't find it anymore. Here is the article: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter10.html. It sounds similar to the realtime reflection maps already in the D3D9 client, except a special blurring algorithm is applied. This technique might hold some promise even if it is a bit computationally expensive, since the lighting environment changes relatively slowly compared to the reflection environment. The lighting environment could be recalculated at 1Hz or even slower, once every two or five seconds, whereas the reflection environment looks bad if the updates are not much slower than the frame rate.

If a realtime irradiance map can be calculated in near real-time, a blurred reflection map may also be possible using a similar (less) blurring algorithm, also recalculated at a slow rate.

I'm hoping for a improvement in the exhaust rendering myself. I'm thinking taking the step from the pseudo-3D (really 2D texture with billboard mapping) rendering we have now to actual 3D rendering. This should improve visuals a great deal.

 

[jarmonik]

@Jarmo: Could you take a look at issue found by Nikogori?
Scenario for easy check attached

Poles :lol:, Fixed.

 

[kuddel]

Poles :lol:, Fixed.

Indeed you did! Thanks

 

[Felix24]

I'm hoping for a improvement in the exhaust rendering myself. I'm thinking taking the step from the pseudo-3D (really 2D texture with billboard mapping) rendering we have now to actual 3D rendering. This should improve visuals a great deal.

Yes! I've been thinking about exhaust rendering too.

 

[jarmonik]

It seems that ordinary deferred rendering has problems with multiple material types within a scene, whereas light-prepass rendering doesn't. Would this be a problem for scenes containing multiple vessels having parts with different material definitions?

Ordinary deferred renderer can have multiple materials. But the problem is the G-buffer that forwards information from geometry/scene rendering stage to screen space light processing stage. From the current material properties we could have pretty much everything else except specular color. Specular color could vary between two choices, white or diffuse color. Probably, a bigger concern would be a lack of MSAA (Multi-Sample AA) which would need to be replaced with heavier SSAA (Super-Sample AA).

I guess the G-buffer layout would be something like albedo.rgb, emission.rgb, specular power, specularity. In our case a reflection from a pixel would be added to emission color, which from a physics point of view would be accurate.

Currently the only light sources in Orbiter I can think of are the sun, planet, and vessel lights. Could new visual effects be realized if a few hundred light sources were available?

We are not talking about hundreds of light sources, merely implementing the current ones in a per-pixel basis instead of per-vertex basis. Currently local light sources (vertex lights) won't interact with normal maps properly.

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. Also, other screen space effects, like light bleeding (glowing) from sun-lit surfaces to near-by-pixels would come more efficiently and naturally in a deferred architecture.

Three major visual effects I'm hoping for in future versions are self-shadowing, realtime irradiance mapping (sunlight reflected off clouds, ocean sunglint, and land, also glow from planet night lights), and blurred reflections (a cross between mirror reflections and specular lighting, like reflections from smooth but not shiny metallic surfaces). Would using deferred or light-prepass architecture make any of these effects easier to realize?

No, deferred does not help there. Shadows are problematic, there are plenty of computer games using commercial renderers and yet still they have problems with shadows. Shadowing is what I might call an unstable effect, how well it works would depend on rendering conditions. If shadowing is limited to self-shadows only not to vessel-on-vessel shadows, then it might get simpler.

Irradiance mapping is a stable and implementable effect, I already had an experimental version of it when the reflection model was implemented but it never went out. SSAO and other screen space effects are also stable. So, the question would be how much the SSAO is worth ?

I am not sure if a deferred is a good idea and I have no need to push it so I can dump it overboard if need be. Every technique has good sides and the bad ones too.

 

[hutchison66]

D3D9 spacecraft 3

I finally got this working in windows 8.1 and Nvidz card,

people keep saying make it your Addons D3D9 compliant well easier said than done you've all probably covered this all before but
I mainly use Spacecraft3 seems like it isn't compatible is there anything I can do to make them work
when I changed to spacecraft 4 it doesn't CTD anymore but no visuals
is there any tips anyone can give me for getting my addons working
I would have thought That spacecraft 3/4 is so important to orbiter I would have thought D3D9 would have made sure it works with it with little change

thanks
David

 

[Cras]

Just completed a shuttle fleet flight with R16.4, everything seemed to be working well, the only oddity was that there was a flicker in the mountains and buildings at Wideawake Int'l as seen through the VC windows.

 

[4throck]

would have thought D3D9 would have made sure it works with it with little change

There's no problem with D3D9 and spacecraft.dll and no changes are needed.

Did you click on "create symbolic links" on the "D3D9 client advanced setup" window?
You must do that in order to get it working.

 

[kuddel]

Is the "forgot to create symbolic links" problem happening too often?
In that case the D3D9Client could create that links *always* without any user-action required.
The downside of course is, that the user looses control of that process.
Some might not like to have symbolic links at all (Linux users might dislike this automatic "feature").

 

[jarmonik]

Doesn't the client display a warning on a splash screen if the links are not present ? Maybe that could be improved ? I'll leave it to you.

 

[Face]

Is the "forgot to create symbolic links" problem happening too often?
In that case the D3D9Client could create that links *always* without any user-action required.
The downside of course is, that the user looses control of that process.
Some might not like to have symbolic links at all (Linux users might dislike this automatic "feature").

Here's hope this work-around is not needed anymore once SC5 (supposedly fully beta-compatible as well) is out. It's quite a crutch IMHO, anyway.

 

[kuddel]

Doesn't the client display a warning on a splash screen if the links are not present ?

Yes it does! ...but nobody reads messages

Maybe that could be improved ? I'll leave it to you.

I'll wait for any reaction from users ("easy spacecraft.dll" vs. "Linux" ).

 

[4throck]

Yes it does! ...but nobody reads messages

Second that. Never noticed that message!

Back on topic, the current Client performs great on my machines.

The only complaint is the current specular reflection. Interesting if you want to create mirrors, but incorrect for other metallic surfaces. At least on my machine/config.

I suggest looking into Physical Based Rendering lighting model as the next step. We already have support for multiple textures (we would need diffuse, specular, gloss, normal), so it's very close.
It would benefit things like solar panels a lot!

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

 

[jarmonik]

The only complaint is the current specular reflection. Interesting if you want to create mirrors, but incorrect for other metallic surfaces. At least on my machine/config.

I suggest looking into Physical Based Rendering lighting model as the next step. We already have support for multiple textures (we would need diffuse, specular, gloss, normal), so it's very close.
It would benefit things like solar panels a lot!

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

That model looks very nice. One problem in our end is that we have tried to match the current rendering with the Orbiter's DX7 inline engine. I suppose we could have different shaders for models build for the inline engine and models build for DX9+, but in that case those models wouldn't be backwards compatible with the inline engine.

Do there actually exists any standards for parameters used to define materials for 3D models ?

 

[4throck]

The model is the same as on OH and the textures are also quite similar! It's the shader that's different.


As far as I know, the material parameters are these:
http://www.marmoset.co/toolbag/learn/pbr-practice



From my tests with Sketchfab, textures are not incompatible.


The main difference is that the albedo texture has no backed shadows. So let's say the interior of a cockpit will be textured as bright as the outside. Shadows are calculated in realtime (ambient occlusion).
From my tests if you don't change the textures they only look darker (because you have textured shadows + computed ones). So we can use the current textures.


Normalmaps are unchanged, so the current ones can be used.


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


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.


Of course, for 100% accurate results you need a new set of textures, but they will still look decent on the inline client.
The oposite is also true, the current texture will look OK on a PBR shader. Perhaps even better because of real-time ambient occlusion.
I don't see a problem there.

 

[hutchison66]

D3D9 Spacecraft

Hi there thanks for the help, yeah the create symbolic links did work but what it really needed was to copy all the spacecraft .ini files to modules/server/config/spacecraft and bingo my ISS A2Z came to life
I can now start working with my addons
thanks for pointing me in the right direction.
just needs tips for improving textures.

 

[kuddel]

As "modules/server/config/" is a symbolic link to "config/" you can copy it to either one. They are the same!

To demonstrate this you can e.g. just add a new file to "config/" and you will see that it also is present under "modules/server/config/".
That's what symbolic links are: They link (or point) to just another location on the file-system. The files (and sub folders) only exist once on your HDD (or SDD)!

 

[hutchison66]

symbolic links

I understand that but just didn't seem to work even after I tried it a few times but by copying the whole folder it worked so I'm happy.
want to give some depth to the textures on the ISSr Zvezda and Zarya
thanks for the help