Project D3D11Client Development

[asmi]

I can only speak for what was changed in the graphics interface:

There were added clbkLoadSurface, clbkCreateSurfaceEx, clbkBeginBltGroup and clbkEndBltGroup callbacks (and surfBltTgt handle) to the graphics client interface, and additionally RP_ISTLDEVICE, RP_REQUIRETEXPOW2 parameters retrievable from clbkGetRenderParam callback.

You can find more information about these changes in GraphicsAPI.h header file.

Thanks for the info. For the implementation point of view, there doesn't seem to be a lot of issues - for instance RP_ISTLDEVICE doesn't make sence in our case since we don't have fixed pipeline, and as far as I understand DX11 doesn't care about texture's requirements, so RP_REQUIRETEXPOW2 is also not applicable.

Ok, I'm going to see if I can fix this over the weekend...

 

[orb]

Ok, I'm going to see if I can fix this over the weekend...

Even if there are no changes in the code, there needs to be made a separate build of graphics client for Orbiter beta users (using binary builds, and not compiling the client from sources), because of changed class interface, which is the basic reason why the graphics client built for Orbiter 100830 doesn't work in Orbiter beta.

 

[asmi]

Even if there are no changes in the code, there needs to be made a separate build of graphics client for Orbiter beta users (using binary builds, and not compiling the client from sources), because of changed class interface, which is the basic reason why the graphics client built for Orbiter 100830 doesn't work in Orbiter beta.

Yes, I understand that. I wonder if there are any breaking changes, i.e. the ones that would prevent graphics client from being compilable against both SDKs (public release and current beta build) at the same time... Do you have any information on that?

 

[orb]

Yes, I understand that. I wonder if there are any breaking changes, i.e. the ones that would prevent graphics client from being compilable against both SDKs (public release and current beta build) at the same time... Do you have any information on that?

Well, from looking at sources of D3D7Client and D3D9Client, I think you need to define at least clbkCreateSurfaceEx in graphics client for Orbiter beta, which isn't defined for Orbiter 2010-P1, but you can use conditional compiling for that without duplicating sources, with for example:

#ifdef RP_REQUIRETEXPOW2

(as I can't see Orbiter version defined anywhere in the SDK headers)

 

[Glider]

Can you brief me in what the actual problem is? So I won't have to dig it out myself

Current 2D code of D3D11Client works this way:
There're 2 types of textures;
1."Texture". these textures have mipmaps number specified by user and no restrictions to format (D3DX11GetImageInfoFromFile() decides what format a texture will have, usually it is same format that was in file) These textures are being used as vessel mesh textures and can be created only by loading from file.They can work only as SRs.
2."Surface" can be used as SRs as well as RTs in 2D code. They must have B8G8R8A8_UNORM format only, have no mipmaps, have GDI-compatibility flag, and must have SampleCount == 1. These "surface"s are being used as HUD, MFD, any 2D buffers, GDI-buffer for back buffer etc."surface"s can be created by conversion from "texture"s, by clbkCreateSurface() or from bitmap. "surface" can be used as mesh texture. (examples: HUD/MFDs)

Blit/Fill and similar functions works only with "surfaces" and if they encounter "texture" they create "surface" of the same size, render "texture" to "surface", and switch these 2 objects with memcpy(). then original "texture" (that have pointer of new "surface") is deleted. (See TextureMgr::ConvertSurfaceToTexture() function ).

in new beta there're:
render params:
RP_ISTLDEVICE or T&L. since it is ancient thing, and FL10/FL11 devices doesn't have problems with it, we may set it to 1 always
RP_REQUIRETEXPOW2 I didn't encouner any problems with power of 2 (all sizes works), so we don't need this.

clbkCreateSuraceEx()
if by CPU access is meant GDI then:
OAPISURFACE_RO all "surface"s can be rad by both CPU & GPU.
OAPISURFACE_RW all "surface"s can be updated by GPU as well, and may work as RTs
OAPISURFACE_GDI all "surface"s can be read by GPU and be blit()'ed to other "surface"s
OAPISURFACE_MIPMAPS "surface" can't have mipmap it is required for D3D11/GDI compatibility
OAPISURFACE_NOALPHA we can't choose format for "surface" it B8G8R8A8 required

clbkLoadSurface()
we can add a method for Texture class to do this, or just create "texture" that will be converted to "surface" anyway.

clbkBeginBltGroup and clbkEndBltGroup
we don't need this. current blitting is done by ID3D11DeviceContext::CopySubresourceRegion() that doesn't require such params.

So, I think in order to make D3D11Client compatible with 2010P2 we need to recompile it and just connect new functions to old 2D code. I see in debugger that the client currently CTDs on things like tex->bTex where tex is NULL (FillSurface()). may be it is because new functions aren't implemented or Orbiter want to fill entire back buffer with some color.

 

[asmi]

Ok, so I've changed shader - now it should run on FL10 without any issues. I've also added specular lighting - now it looks even more beautiful For now I've hardcoded specular power of 30, which assumes medium to high reflective material, which covers much of real metals.
I think that's it for vessel beacons lighting - I think self-shadowing can wait a bit - so we can check off first item in TODO list as completed Now I'm going to try to convert it to latest beta and make it work
Source code is as always in my fork: https://bitbucket.org/asmi/ovp Looks like this will be the last version that is built against and so compatible with 2010 P1 build, next one (hopefully ) will work with the beta.

---------- Post added at 21:47 ---------- Previous post was at 20:44 ----------

Ok, here is the first problem - comment for method clbkCreateSurfaceEx reads:

* \note The attribute flag can contain one of the following main attributes:
* - OAPISURFACE_RO: create a surface that can be read by the GPU pipeline, and that can be updated from system memory.
* - OAPISURFACE_RW: create a surface that can be read and written by the GPU pipeline, and that can be updated from system memory.
* - OAPISURFACE_GDI: create a surface that can be read and written from the CPU, and can be blitted into an uncompressed RO or RW surface without an alpha channel
* In addition, the flag can contain any combination of the following auxiliary attributes:
* - OAPISURFACE_MIPMAPS: create a full chain of mipmaps for the surface if possible
* - OAPISURFACE_NOALPHA: create a surface without an alpha channel

In reality first two flags are not defined, instead we have this:

#define OAPISURFACE_TEXTURE 0x0001 ///< Surface can be used as a texture (e.g. by associating it with a mesh)
#define OAPISURFACE_RENDERTARGET 0x0002 ///< Surface can be rendered to by the graphics device
#define OAPISURFACE_GDI 0x0004 ///< A HDC context can be requested from the surface for GDI drawing
#define OAPISURFACE_SKETCHPAD 0x0008 ///< A Sketchpad context can be requested from the surface for Sketchpad drawing
#define OAPISURFACE_MIPMAPS 0x0010 ///< Create a full chain of mipmaps for the surface. If loaded from file, add any missing mipmap levels
#define OAPISURFACE_NOMIPMAPS 0x0020 ///< Don't create mipmaps. If loaded from file, ignore any mipmap levels present
#define OAPISURFACE_ALPHA 0x0040 ///< Create an alpha channel for the surface. If loaded from file, add an alpha channel if required
#define OAPISURFACE_NOALPHA 0x0080 ///< Don't create an alpha channel. If loaded from file, strip any existing alpha channel
#define OAPISURFACE_UNCOMPRESS 0x0100 ///< Create an uncompressed surface. If loaded from file, uncompress if required.
#define OAPISURFACE_SYSMEM 0x0200 ///< Create the surface in system (host) memory
#define OAPISURFACE_RENDER3D 0x0400 ///< Create a surface that can act as a target for rendering a 3D scene

So for now I'm going to work with flags that are actually defined, and looks like we've gotta wait for next beta update to get those new flags covered...

---------- Post added at 23:27 ---------- Previous post was at 21:47 ----------

Ok, guys, I did a conversion using very "naive" approach - see code diff for details, and to test is has decided to take it for a ride. I took off KSC runaway and reached LEO without any problems:

However as I've tried to land, it did crash at some point during "ducking" (bouncing off atmosphere during reentry), stack trace suggested that it had something to do with GDI. So I'd appreciate if anyone can give it a try to see how things are. Glider, I'm going to need your assistance with this fix as I have very little knowledge about workings of 2D in the client.

Also there is one more thing that I've noticed - Sun is displayed only if "Planetaruim mode" is enabled. Not sure if this is a new bug, or an old one - since I never tried to get to space before "upgrade"

 

[Lucy]

I've no log or trace yet (haven't run it in the debugger yet) but all I got on my testbed install was a CTD. And Windows' dead helpful "this isn't working" message. :dry:

 

[asmi]

I've no log or trace yet (haven't run it in the debugger yet) but all I got on my testbed install was a CTD. And Windows' dead helpful "this isn't working" message. :dry:

Well, thanks for giving it a ty anyways
Did you build it from sources or just used dll that is in the source control? I've just added *.pdb file that can help with diagnosis in this case. Also I'm not sure how app would react to missing config file - so did you configute a settings for the module in the "Video" tab?

 

[Glider]

Ok, so I've changed shader - now it should run on FL10 without any issues.

Looks great, especially with enabled normal maps in the night.

In reality first two flags are not defined, instead we have this:

I think it doesn't change much:
OAPISURFACE_TEXTURE any "surface" can be used as texture
OAPISURFACE_RENDERTARGET any "surface" works as render target
OAPISURFACE_GDI any "surface" works with GDI
OAPISURFACE_SKETCHPAD any "surface" works with sketchpad. both GDIPad and D3D11Pad.

OAPISURFACE_MIPMAPS and OAPISURFACE_NOMIPMAPS we can't create mip maps for "surface". D3D11/GDI compatibility requirement.

OAPISURFACE_ALPHA and OAPISURFACE_NOALPHA we have only B8G8R8A8 format available for "surface". Another D3D11/GDI compatibility requirement.

OAPISURFACE_UNCOMPRESS "surface" cannot be compressed. D3D11/GDI compatibility requirement also.

OAPISURFACE_SYSMEM it is D3D9 specific thing. though, may be in the case of DX10/11 it means STAGING usage. Anyway we don't need STAGING textures for 2D. all "surface"s have DEFAULT usage.

OAPISURFACE_RENDER3D all "surface"s have RT bind, so they all can work as render targets.

So, it seems that your code is correct. + see comment below.

Ok, guys, I did a conversion using very "naive" approach - see code diff for details, and to test is has decided to take it for a ride. I took off KSC runaway and reached LEO without any problems:

However as I've tried to land, it did crash at some point during "ducking" (bouncing off atmosphere during reentry), stack trace suggested that it had something to do with GDI. So I'd appreciate if anyone can give it a try to see how things are. Glider, I'm going to need your assistance with this fix as I have very little knowledge about workings of 2D in the client.

I updated my 2010P2 version of the project with latest code from your fork, compiled it and tested. I tried XR2, XR5, default DG, with debug and release builds(speed optimizations enabled + SSE2, attached to this message). I took DG and flew to orbit, made 1 orbit and landed somehere in ocean. Also tried a bit fly XR2 and XR5. There were no CTD. :hmm: (only bug with ClearRTV() when MFD doesn't redraw itself) When does this CTD happens and what it has to do with GDI ? I used 111105 Orbiter beta.

Also there is one more thing that I've noticed - Sun is displayed only if "Planetaruim mode" is enabled. Not sure if this is a new bug, or an old one - since I never tried to get to space before "upgrade"

I didn't saw it too. Sun worked correctly.

 

[asmi]

Got it just now. Texture.cpp:59.
D3D11: ERROR: ID3D11Device::CreateTexture2D: Returning E_OUTOFMEMORY, meaning memory was exhausted. [ STATE_CREATION ERROR #105: CREATETEXTURE2D_OUTOFMEMORY_RETURN ]
LOL Something has requested a "texture" with following parameters:
W: 1438129258
H: 3893313765
data: 0x0002b9a6
Stack trace:

ntdll.dll!76ec15de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!76ec15de()
ntdll.dll!76eb014e()
d3d11.dll!173b8506()
d3d11.dll!173b9c80()
D3D11SDKLayers.dll!0f3e215d()
D3D11Client.dll!Texture::Texture(unsigned long w, unsigned long h, void * data) Line 59 + 0x25 bytes C++
cccccccc()

Look at the top frame - looks like there is a bigger problem somewhere

---------- Post added at 11:11 ---------- Previous post was at 11:05 ----------

UPDATE:
I've loaded symbols and got more useful stack trace:

ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
d3d11.dll!CDevice::CreateTexture2D_Worker() + 0x144 bytes
> D3D11Client.dll!TextureMgr::CreateTextureFromBitmapRect(HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 972 + 0x37 bytes C++
D3D11Client.dll!TextureMgr::CopyBitmap(Texture * tex, HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 483 + 0x1c bytes C++
D3D11Client.dll!D3D11Client::clbkCopyBitmap(void * pdds, HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 506 C++
orbiter.exe!00433565()
[Frames below may be incorrect and/or missing, no symbols loaded for orbiter.exe]
orbiter.exe!004293bb()
orbiter.exe!0045633e()
D3D11Client.dll!D3D11Client::clbkRenderScene() Line 202 + 0x1a bytes C++
orbiter.exe!00418203()
orbiter.exe!0041b77f()
orbiter.exe!0041b978()
orbiter.exe!004b176f()
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes

Still have to clue what's going on...
UPDATE2:

First-chance exception at 0x0403a023 (D3D11Client.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x76ec15de in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000.

Looks like we've got a classic "memory-run-through"

---------- Post added at 19:29 ---------- Previous post was at 11:11 ----------

Just tried to do the same thing again - and everything went just fine... Odd thing...
Allthough I've seen a bunch of fist-chance COM exception in debug window when I switch to VC, so maybe it's somewhere in that area.

 

[Glider]

Oh, sorry, it seems I didn't look at this problem close enough... :beathead:
I'm getting the same exceptions in VC modes and 2 access violations after exit, but in my case I don't get any CTDs during simulation.
commenting vVessel::RenderVC() completely fixes it, so I think it definitely has to do something with HUD/MFD/Mesh.fx/Vessel.fx. I will try to find exact reason for this bug now.

UPDATE:
I've fixed com exceptions by changing code of clbkReleaseSketchpad:

if( cfg->SketchPadMode == 1 ) {			//GDI for surfaces, D3D11Pad for backbuffer	[mode 1]
		SURFHANDLE surf = Skpad->GetSurface();
		if( surf ) {
			[B]if( surf == HUDTEX ) {
				d3d11_pad = (D3D11Pad*)Skpad;
				delete d3d11_pad;
				return;
			}[/B]
			gdi_pad = (GDIPad*)Skpad;
			clbkReleaseSurfaceDC( gdi_pad->GetSurface(), gdi_pad->GetDC() );
			delete gdi_pad;
			return;
		}
		else {
			d3d11_pad = (D3D11Pad*)Skpad;
			if( cfg->RThread ) {
				LeaveCriticalSection( &Resources );
				SetEvent( ResourceReleased );
			}
			delete d3d11_pad;
			return;
		}
	}

and in the clbkGetSketchpad:

if( [B]HUDTEX &&[/B] HUDTEX == tex ) {
		SC->PBuffers_counter++;
		if( cfg->RThread ) {
			SetEvent( ResourceRequest );
			EnterCriticalSection( &Resources );
		}
		return new D3D11Pad( surf );
	}

 

[asmi]

I've fixed com exceptions by changing code of clbkReleaseSketchpad:
and in the clbkGetSketchpad:

You are genious! I've incorporated your fix & committed it to my fork - it seems to be working just fine now!

---------- Post added at 11:32 ---------- Previous post was at 11:05 ----------

Also I've updated project's Wiki to reflect current state of affairs.

 

[asmi]

Just to give you guys an update, I'm working on HDR lighting and some related effects (like gloom). Don't have ETA at this point as it's quite a complicated thing (especially since I'm limited to FL10, which rules out some really useful features)...

 

[RacerX]

So will this make it so I don't pass through the ISS or other ships now when docking?

 

[asmi]

So will this make it so I don't pass through the ISS or other ships now when docking?

No, this is completely unrelated thing, allthough this could be doable too...

 

[asmi]

Another great thing is arriving: I have implemented HDR lighting and a number of post-processing effects, namely bloom, camera vignetting and tone mapping.
Here are some screens(click to enlarge):

Check out those two:

They were made at almost the same moment, first one looking at Earth, second one looking outwards to the space. Note that stars on those screens have different brightness - this is tone mapping at work. And of course bloom looks wonderful to my taste

Currently this whole thing is implemented entirely using Compute Shaders 5.0, so FL11 only at the moment. I've found CS 4.0 too crippled - it doesn't even support Texture2DMS objects (not to mention really useful RWTexture2D's, which I use a lot in current implementation) - so I've decided to create a version for FL11 first, and then figure out a way to create a separate branch for FL10. In latter case we'll probably won't be using CS as much as in FL11, so this will require multiple "render quad to texture"'s, which potentially can become a performance problem. And looks like I will need your help to brainstorm possible approaches to this issue. Later I will describe current algorithm to aid this brainstorm, and hopefully we'll come up with something. Now it's time to get some sleep

Cheers!

 

[asmi]

Here are two screenshots of the same moment with all PP effects on (first shot) and off (second one):


And, last but not least - one more screenshot specially for Glider

I've marked down a problem region - sun and beacons are still not being rendered properly. From the shot you can see that part of beacon is being covered by runaway, the same effect is for the sky - that's why Sun is not visible for me. If you could take a look and fix it - I'd really appreciate that!

Oh, and Face - please merge in back to your branch.

That's it for now

 

[NovaSilisko]

Think it would be possible to tie bloom to the amount of light on a face? That's the main thing that bugs me about bloom in most renderers - it's nearly global, anything that's even somewhat -bright- will glow fiercely. If it's something brightly colored in direct, unfiltered sunlight, though...

 

[dumbo2007]

Great work, I am diligently following this and looking forward to a beta soon

Are the textures on the DG bump mapped ? would it be possible to do it for other vessels using custom maps ?

 

[asmi]

Think it would be possible to tie bloom to the amount of light on a face? That's the main thing that bugs me about bloom in most renderers - it's nearly global, anything that's even somewhat -bright- will glow fiercely. If it's something brightly colored in direct, unfiltered sunlight, though...

The way effect works is the following - it "glows" pixels which have any color component value (red, green or blue) higher than certain threshold value. We can tweak this value until we're satisfied with the visual result. Actually all effects that I've implemented are somewhat "tweakable", I've just set them up to look good to my taste.

---------- Post added at 08:10 ---------- Previous post was at 08:08 ----------

Great work, I am diligently following this and looking forward to a beta soon

You can get current build any time you want, as we include pre-built binary in the source control with each change.

Are the textures on the DG bump mapped ? would it be possible to do it for other vessels using custom maps ?

Yes, and yes. But I don't know details on how exactly this works - I think Glider has implemented that so we need to ask him.