New Release D3D9Client Development

[kuddel]

Beta D3D9Client bug: Using the HUD extend/retract switch in the DG VC results in an immediate CTD. It works fine in the inline client.

Thanks! Fixed!
It was one of those "uninitialized variable + unchecked access" things
---------
Revision: 592
Author: Kuddel
Date: Freitag, 8. April 2016 19:45:55
Message:
- fixed VC HUD access violation reported by DaveS
(http://www.orbiter-forum.com/showthread.php?p=530775&postcount=3701)
----
Modified : /trunk/Orbitersdk/D3D9Client/VVessel.cpp

---------- Post added at 19:51 ---------- Previous post was at 19:47 ----------

Yes it does!

DaveS's version works for me also ( xpsp3 ).

Thanks for the feedback!
So, we've got VS2010 and VS21012 to build "XP ready"(TM) versions.
Next I'll have to dig a bit deeper into the VS2015 builds.

Thanks again,
Kuddel

---------- Post added at 20:18 ---------- Previous post was at 19:51 ----------

Revision: 592
Author: Kuddel
Date: Freitag, 8. April 2016 19:45:55
Message:
- fixed VC HUD access violation reported by DaveS
(http://www.orbiter-forum.com/showthread.php?p=530775&postcount=3701)
----
Modified : /trunk/Orbitersdk/D3D9Client/VVessel.cpp

That was only half of the fix, sorry. Revision 593 contains the other half
There's nothing about good ol' testin'
/Kuddel

 

[kuddel]

Hi all,
another "XP ready"(TM) build is ready!
I think I got the VS2015 projects set up to be able to build releases that work on XP-Systems a well:

@Ripley: Would you be so nice and check this build as well?

I've tested it on my Virtual XP machine, but to be sure I would like to have it tested on "real" hardware/software.

Thanks in advance,
Kuddel

 

[fort]

Hi all,
another "XP ready"(TM) build is ready!
I think I got the VS2015 projects set up to be able to build releases that work on XP-Systems a well:
@Ripley: Would you be so nice and check this build as well?

Kuddel

Works here. At least not any CTD.

 

[kuddel]

Works here. At least not any CTD.

Merci bien!

 

[Ripley]

...@Ripley: Would you be so nice and check this build as well?...

Oh yes it does! :tiphat:

 

[kuddel]

D3D9Client for Orbiter BETA r54

So here we have it: an "official" release (most probably "XP ready"(TM) :thumbup: )
D3D9Client Beta 23.1 -for Orbiter BETA r54

 

[kuddel]

Oh yes it does! :tiphat:

Grazie mille!

 

[fort]

So here we have it: an "official" release (most probably "XP ready"(TM) :thumbup: )
D3D9Client Beta 23.1 -for Orbiter BETA r54

Meci, kuddel. To have the possibility to stay actually with xp and follow the developpement of D3D9...Danke.

 

[Ripley]

So here we have it: an "official" release (most probably "XP ready"(TM) :thumbup: )
D3D9Client Beta 23.1 -for Orbiter BETA r54

Working perfect too!

 

[kuddel]

Meci, kuddel. To have the possibility to stay actually with xp and follow the developpement of D3D9...Danke.

You're welcome.:thumbup:
Since we develop old technology (DirectX 9 is from 2002 IIRC) why should we stop supporting old Operating-Systems :lol:

Good night,
Kuddel

 

[Cras]

I can't reproduce the problem anymore after the fix. There was also a similar problem in stock HSI MFD.

Here is a new build. Maybe the D3D9Client.dll extracted to orbiter root. If the problem is still present then you you post a scenario.

That appears to have fixed it!

 

[Felix24]

I need to create a blurred version of the environment map

How well would it work of you used a mipmap of the environment map?

 

[jarmonik]

How well would it work of you used a mipmap of the environment map?

Mipmaps alone are not sufficient enough due to low resolution and interpolation. However, if each mipmap level is blurred lot enough to cover the lose of resolution, it seems to work pretty well and provides a smooth shift from crisp to blurry. The latest implementation in svn://mirror.orbiter-radio.co.uk/D3D9client/branches/Experiments uses 3-mipmap levels to do the trick.

Level 0 - 512px mirror clear
Level 1 - 256px blurry
Level 2 - 128px blurrier
Level 3 - 64px blurriest

 

[4throck]

Interior lights can be 'baked' onto the textures, which is what I did in this addon for the old DG: DG Textures Enhancement

Indeed, I did the same for my Orion CEV. :thumbup:

But realtime engines are moving away from it because that's a very limited solution.

Imagine that your cockpit (or spacestation interior...) is composed of many meshes. Imagine a "cockpit editor" where each mesh can be placed freely and rotated. You can't bake a texture for that sort of thing...
Realtime ambient occlusion is indeed slow, but most games seem to use it nowadays. Sometimes it's called shadow detail or something, but it's there.

 

[jarmonik]

Test Build

This build is intended for testing for developers and 3D modelers.

The roughness map is implemented as <diffuse name>_rghn.dds, currently only isotropic maps are supported. I suppose, it could be nice to have a support for anisotropic too but that would require some models and textures for testing purposes.

The Skylab-B model should be working properly when the specular maps are labelled as reflection maps with the _refl.dds identifier. Also, the current build has a specular model selector added in D3D9DebugControls which allows to switch between Phong, Blinn and Ward. Real time switching won't be supported at some point later on.

In the current test build all meshes are rendered with PBR.fx technique unless EnablePBR is switched to 0 from D3D9Client.cfg. Local light sources do not interact with materials properly. It would take some time and thinking to get that sorted out.

It would be a good idea to develop a working rendering model and then create a proper documentation and description of it. Like Felix24 said earlier about keeping separate specular and reflection models, I do agree with that. Like we have already discussed about a following points:

1) Due to forward/backwards compatibility issues, we can't really change the meaning of specular color. In DX7 it only effects in how sunlight is applied to a mesh. If this is changed then we will see ugly reflections everywhere.
2) Direct sunlight is a lot more intense than any reflection from an environment.

Since, we already have a specular power stored in alpha channel of specular map, we could keep it that way.

So, in a primary basis a _refl map would be for a reflective materials (i.e. metals) interacting with environment and _spec would be for less reflective materials interacting only with sunlight.

In the current setup _refl map does not interact with sunlight only with environment, which sounds a bit illogical. We would need to have a working cSpec present at all times, So, if _refl map is present and _spec map is not then we could simply use cRefl for cSpec too: cSpec.rgb = cRefl.rgb; We can't really include gMrtl.specular.rgb in that equation because the material is likely configured to work with the DX7 and could make things worse. In this case a specular power (i.e. roughness) would come from a roughness map or from a specular material setup.

Also, If _spec is present and _refl is not then we could construct cRefl:
cRefl.rgb = cSpec.rgb * gMtrl.reflect.rgb;

EDIT: Clarification:
This cSpec.rgb = cRefl.rgb; and this cRefl.rgb = cSpec.rgb * gMtrl.reflect.rgb; already exists in the current build.

 

[kuddel]

D3D9Client (Beta23.1) for BETA r55

Due to changes in the API D3D9Client had to be re-build for the latest Orbiter BETA (r55).
Package can be found here

 

[Ripley]

Stretched splash screen @ 1920*1080

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:

 

[Felix24]

Cool effect! How much more can the blur be increased? I'm interested in seeing an extremely blurred environment map, because 1) there are materials that could still use more blur, and 2) I think it could be directly applied as an irradiance map.

For example, the Kibo module has a more blurred reflection than the Columbus module. (http://iss.jaxa.jp/en/kibo/about/images/s134e010585_ll.jpg)

In the current setup _refl map does not interact with sunlight only with environment, which sounds a bit illogical. We would need to have a working cSpec present at all times, So, if _refl map is present and _spec map is not then we could simply use cRefl for cSpec too: cSpec.rgb = cRefl.rgb; We can't really include gMrtl.specular.rgb in that equation because the material is likely configured to work with the DX7 and could make things worse. In this case a specular power (i.e. roughness) would come from a roughness map or from a specular material setup.

Also, If _spec is present and _refl is not then we could construct cRefl:
cRefl.rgb = cSpec.rgb * gMtrl.reflect.rgb;

I think we should still keep the _spec and _refl separate. If _spec is not present, then gMtrl.specular.rgb should be used, and if _refl is not present, gMtrl.reflect.rgb should be used, without using data from another map. I also think _rghn should be independent from gMtrl.specular.a.

In saying this, I may be missing the point of PBR entirely. I'm not entirely sure how it boils down, or how it would change how I create textures.

What if we stored the roughness value in the alpha channel of the _refl map instead of in its own _rghn map?

If possible, I'd like to see how anisotropic textures would look. If we wanted to use anisotropic textures, we could store the angle in its own _anis map. It would likely only need one channel for the angle, 0-255 being mapped to 0-Pi.

I noticed in this build that normal maps aren't working at all.

whether for orbiter beta ?

I think it's for r54.

 

[jarmonik]

How much more can the blur be increased?

It should be possible to increase with one more mip level.

I think it could be directly applied as an irradiance map.

It could be applied but it wouldn't work properly. Irradiance map is an integral of incoming light for a given normal vector. It isn't a blurred map even if it may look like it. The difference would be more obvious in a scenario where a half of the map is covered by planet and other half by blackness of space. More immediate problem is a lack of difference between white and bright. Having an evnmap in HDR would help with irradiance.

In saying this, I may be missing the point of PBR entirely. I'm not entirely sure how it boils down, or how it would change how I create textures.

The way I understand it is this: A traditional rendering is a rendered based/focused approach where a modeler is "programming" the renderer to do something by providing materials and data in a form of a textures. In D3D9 a modeler is expected to provide both _refl and _spec maps because that's the way the renderer is working or doing things. So, a modeler would need to know/understand the inner workings of the rendered to get something done. The PBR would switch the focus from a renderer based thinking into a material property based thinking, providing a better compatibility and less renderer specific "need to know" things.

It is currently possible to switch the shader code, in a per mesh group basis, based on existence of a texture or a material properly.

What if we stored the roughness value in the alpha channel of the _refl map instead of in its own _rghn map?

1. Roughness is usually provided as a separate map.
2. Working with alpha channel is problematic in may programs.
3. Anisotropic roughness would need two channels.

If possible, I'd like to see how anisotropic textures would look. If we wanted to use anisotropic textures, we could store the angle in its own _anis map. It would likely only need one channel for the angle, 0-255 being mapped to 0-Pi.

Using "_anis" to identify anisotripic roughness is a good idea. Although I don't see any point in using a separate texture for it. It would be pretty much like implementing a normal mapping with a separate textures for x, y and z-components.

I think we should still keep the _spec and _refl separate. If _spec is not present, then gMtrl.specular.rgb should be used, and if _refl is not present, gMtrl.reflect.rgb should be used, without using data from another map.

I fail to see the point. Let's presume that a model provides only one map for it's specular/reflection behavior. How do we take the best out of it ? How does a 3D modeler expect it to work ?

I also think _rghn should be independent from gMtrl.specular.a

Technically it is already, _rghn replaces any existing gMtrl.specular.a (i.e. specular power/roughness)

Also, a specular power is a Phong, Blinn style to represent roughness, so, technically they are one and the same thing. For an example, in a Ward style shading a specular power is not applicable no such thing exists.

 

[4throck]

This build is intended for testing for developers and 3D modelers.

Perhaps it's related to the latest Orbiter beta, but I can't get the D3D9 Test Build to work at all. Orbiter launchpad loads, but there's no Video tab...

**** Orbiter.log
000000.000: Build Apr 12 2016 [v.160412]
000000.000: Timer precision: 4.26666e-007 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]
============================ ERROR: ===========================
Failed loading module Modules\Plugin\.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================
000000.000: Module ScnEditor.dll ......... [Build 160412, API 160412]
000000.000: Module Rcontrol.dll .......... [Build 150906, API 150906]
000000.000: Module HUDDrawer.dll ......... [Build 150907, API 150906]
000000.000: Module Framerate.dll ......... [Build 150906, API 150906]
000000.000: Module FlightData.dll ........ [Build 151010, API 151010]
000000.000: Module ExtMFD.dll ............ [Build 150906, API 150906]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
000000.000: Module LuaConsole.dll ........ [Build 160412, API 160412]
000000.000: Module ScriptMFD.dll ......... [Build 150906, API 150906]
000000.000: Module CustomMFD.dll ......... [Build 151101, API 151101]
000000.000: Module LaunchMFD.dll ......... [Build 150907, API 150906]
000000.000: Module LuaMFD.dll ............ [Build 160412, API 160412]
000000.000: Module TransX2.dll ........... [Build 150907, API 150906]
000000.000: Module Meshdebug.dll ......... [Build 150906, API 150906]
000000.000: Module TopoMapMFD.dll ........ [Build 160404, API 160402]
000000.000: Module D3D9Client.dll ........ [Build 160412, API 160402]
000000.000: D3D9: ERROR: Failed to Shutdown TileBuffer()
============================ ERROR: ===========================
Failed loading module Modules\Plugin\D3D9Client.dll (code 1114)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================
000000.000: Module DX9ExtMFD.dll ......... [Build 150107, API 100830]