New Release D3D9Client Development

[Loru]

If you have an old machine with Win XP then you don't really benefit from DX9.

I beg to differ

If GPU is Shader 2.0 capable, then antialiasing, normal maps, better lightning improves visuals a lot.

 

[Ripley]

I made a small change that might fix this issue. Let's just hope it doesn't break anything else.

Here is a beta for testing...

Unfortunately the Antares VC problem still persists...

 

[jarmonik]

I tried to installed Anteras from Orbithangar but couldn't get it to work. Lot's of errors in Orbiter.log. Looks like it's depended about a lot of other add-ons those are not coming with the base package.

Can you run this add-on without having multistage2.dll and spacecraft3.dll ?
If not then I am not wasting any more of my time with this, it's hopeless.

 

[Cras]

for Antares you need Jarvis, which is multistage.

When you install it right and have the right addons to go with it, it works just fine, aside from the goofy-ness reported earlier.

 

[asbjos]

Hey. I have a problem with the R9 beta. I use Orbiter_ng 100830.
When I activate the D3D9 client in the Modules tab, Orbiter instantly crashes with the message "orbiter.exe has stopped working".

When I paste in the R8 version of the client and activate it again, Orbiter runs as usual, so it's a bug in the new client module.

 

[Ripley]

Did you try the latest (maybe different) R9, just released?

 

[jarmonik]

I can reproduce the issues reported with Anteras but I am not sure what I can do about it. A surface management is a nightmare at a moment because the Orbiter and add-ons are designed for a DirectX 7 and the requirements of DirectX 9 are somewhat different, surfaces are more specialized in a specific purposes. There are no generic surfases those would fit for every purpose at the same time, so the client must convert a surface from one type to an another based on it's use.


I have debugged the GET display problem and it would seem that the reason why it doesn't work in the D3D9Client is that the D3D9Client actually does what it is commanded to do. The Anteras/Time.dds is filled with a black color. It would seem that the DX7 inline engine is ignoring the fill command and is threfore letting the display to work.

The same will apply into the Anteras/MC06.dds, the surface is cleared that's why it will disapear. (Line 994) (DX7 inline engine will probably ignore the "Clear" command)

(990: 20.59s 2us)(0x1330) == Begin Scene ==
(991: 20.60s 3us)(0x1330) Creating D3D9 SketchPad...
(992: 20.60s 7us)(0x1330) UpdateSurface 0x3D140F0 (???) -> 0x3D148D0 (???) (256,256)
(993: 20.60s 7us)(0x1330) ...D3D9 SketchPad Released
(994: 20.60s 6us)(0x1330) Clear Surface 0x3CEAF78 (Antares\MC06.dds)(1024,1024)
(995: 20.60s 167us)(0x1330) Texture 0x3CF68C0 (Antares//RCS_CH4exhaust.dds) found from repository. ReferenceCount=2
(996: 20.60s 6us)(0x1330) StretchRect 0x3CF6380 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(997: 20.60s 2us)(0x1330) StretchRect 0x3CF62A0 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(998: 20.60s 2us)(0x1330) StretchRect 0x3CF62A0 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(999: 20.60s 2us)(0x1330) StretchRect 0x3CF6380 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(1000: 20.60s 2us)(0x1330) StretchRect 0x3CF6380 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(1001: 20.60s 2us)(0x1330) StretchRect 0x3CF6380 (???) -> 0x3CEAF78 (Antares\MC06.dds) (32,27)
(1002: 20.60s 2us)(0x1330) StretchRect 0x3CF61C0 (???) -> 0x3CEAF78 (Antares\MC06.dds) (43,23)

Should I implement a hack in the client that would try to "guess" when it should "ignore" some commands ?

 

[Ripley]

Thanks Jarmo.
I'm still waiting for an answer at FOI, about the method they used for drawing this GET display...

 

[jarmonik]

Thanks Jarmo.
I'm still waiting for an answer at FOI, about the method they used for drawing this GET display...

It doesn't really matter anymore. It looks like they are using oapiBlt to construct the GET display. They just need to remove the un-necessary clear and fill commands.

---------- Post added at 16:20 ---------- Previous post was at 16:06 ----------

There is an other minor issue I noticed. It seems that they like to use DXT5 texture compression and it may attract trouble. DXT3 and DXT5 should be avoided unless you really need the alpha channel. D3D9Client will decompress the surfaces if oapiBlt() or oapiGetDC() is used. DXT1 is decompressed in a GDI compatible format. Others are not.

Here is a decompression chart:
DXT1 -> X8R8G8B8 (GDI compatible)
DXT3 -> A8R8G8B8 -> GetDC() will fail
DXT5 -> A8R8G8B8 -> GetDC() will fail

 

[Kendo]

Just to point out, I use a texture I made for the ISS, its DTX 5 ARGB 8pp using Photoshop with Nvidia plugin, and works perfectly, no errors. You get a better texture using DTX5.

 

[DaveS]

Jarmo, I know this was discussed about a year or so ago, but any idea if reflection maps could be implemented?

 

[orb]

Just to point out, I use a texture I made for the ISS, its DTX 5 ARGB 8pp using Photoshop with Nvidia plugin, and works perfectly, no errors. You get a better texture using DTX5.

But you use the DXT5 texture as a static texture for the mesh (which is completely fine, and fully supported in compressed form by the graphics client), and not for blitting it on dynamic elements in cockpit (which needs to be in uncompressed form first, to be used there).

 

[Kendo]

O.K Orb, thanks. While i,m on the subject of textures, will, or does D3D9 support planet bump/normal rendering, as in D3D11?

 

[jarmonik]

Jarmo, I know this was discussed about a year or so ago, but any idea if reflection maps could be implemented?

It's possible. But at first, the scene rendering would need to be re-worked so that the scene can be render from a different camera positions. Also additional rendering passes should ignore the planetarium mode and some other small details.

A Vessel with a reflection map could not reflect any parts from the vessel it self. Unless we find some means to render the reflection maps for some specific mesh groups.

---------- Post added at 18:47 ---------- Previous post was at 18:40 ----------

O.K Orb, thanks. While i,m on the subject of textures, will, or does D3D9 support planet bump/normal rendering, as in D3D11?

I have been thinking about it. I would hope to combine specular mask, night lights and normal map into the same DXT1 texture. It would be more efficient in a terms of a memory and a harddrive activity. At first we would need a tool that can pack the information in a texture like this.

Red Channel = Normal Map lookup table x-coordinate
Green Channel = Normal Map lookup table y-coordinate
Blue Channel = Nightlights intensity level
Alpha Channel = Specular Mask

 

[Felix24]

At first we would need a tool that can pack the information in a texture like this.

Red Channel = Normal Map lookup table x-coordinate
Green Channel = Normal Map lookup table y-coordinate
Blue Channel = Nightlights intensity level
Alpha Channel = Specular Mask

Currently, the nightlights texture is stored and displayed with red, green, and blue channels, allowing changes in color and saturation in addition to lightness. Changing to a lightness-only model would reduce some flexibility, but the benefit of fitting it all into one ARGB texture might be worth it for some planets.

 

[jarmonik]

Currently, the nightlights texture is stored and displayed with red, green, and blue channels, allowing changes in color and saturation in addition to lightness. Changing to a lightness-only model would reduce some flexibility, but the benefit of fitting it all into one ARGB texture might be worth it for some planets.

Considering Martin's latest work with the night lights I suppose you are right. But we could have a nightlights color lookup table or a "non-linear" function to compute the color but it might get too complicated. So, let's forget the idea.

 

[jarmonik]

Ok, Here is an alpha release for experimentation with the reflections. It requires a lot of design how to properly implement the reflections. This process will require some feedback from a model designers.

Currently only a focus vessel has environment map. Having something in vessel's cargo bay may cause some sudden changes in the reflections and there are still a some other bugs remaining.

Reflections with a normal maps are problematic because the normals must be converted from tangent space to world space in pixel shader. Object space normal mapping might be less heavy in this case. Despite of that a modern machine can still get 150-400Fps depending about the situation.

Here is a normal mapped XR2. Notice the reflection of earth's horizon in the left rudder.

Binaries for 2010-P1 only. Shader Model 3.0 Required

 

[DaveS]

Ok, Here is an alpha release for experimentation with the reflections. It requires a lot of design how to properly implement the reflections. This process will require some feedback from a model designers.

How do apply environment maps on vessels? Looked over the document in the package, nothing there.

 

[Kendo]

Good work Jarmonik. But, as most of the models for Orbiter lack the quality for reflections it would make them look worse. If they had a higher poly count then great. By all means go ahead with this, but with the option to turn reflections off. As D3D9 is becoming more amazing as time goes by, many would want a choice on options. :tiphat:

 

[jarmonik]

How do apply environment maps on vessels?

That's a good question. I don't know. Currently it is applied for the focus vessel automatically. Suppose a specular map might help to control how the reflections are effecting some specific parts. I believe there are some mesh group specific flags (see 3DModel.pdf page 6) those could be used.

The environment map can be visualized from the debug controls. EDIT: And enabled/disabled from the advanced setup dialog.

Considering that the reflections are not working very well with most vessels by default then the reflections should be disabled by default. The question is how to enable them for a vessels those can properly use them ?

EDIT2: The environment map is rendered in a world space (ecliptic frame of reference). Due to this reason the env-map doesn't change even if the vessel is rotating, therefore, requiring a lower update frequency.
EDIT3: The so called "HDR" equation can be enabled from a pixel shaders, atleast for XR2 it will give a better results in some scenarios.

if (gEnvMapEnable) {
		float3 s = 0;
		float  r = pow(saturate(smoothstep(0.0, 80.0, cSpe.a)), 2);  // Specular to reflection mapping
		float  b = (1.0-r)*0.04;  // blur
		float3 v = normalize(reflect(-CamW, nrmW));
		s += texCUBE(EnvMapS, v);
		s += texCUBE(EnvMapS, v+float3(b,b,0));
		s += texCUBE(EnvMapS, v+float3(0,b,b));
		s += texCUBE(EnvMapS, v+float3(b,0,b));
		spec += s*(r*0.25);
		//spec += s*r;
	}
	
	if (gUseEmis) diff += tex2D(EmisS, frg.tex0).rgb;

    // -------------------------------------------------------------------------
	   float3 color  = cTex.rgb * saturate(diff) + saturate(spec);   // Standard lighting
    // float3 color = 1.0f - exp(-1.0f*(cTex.rgb*diff+spec));		 // "HDR" lighting
    // -------------------------------------------------------------------------