Project D3D11Client Development

[Glider]

That sounds promising. You are more than welcome to contribute to OVP, of course. I'm not in the position to allow contribution (or disallow it, for that matter), so you don't have to ask me at all.

I will keep the sources in Mercurial on BitBucket, since I have Martin's SVN repository mirrored there, as well as Jarmo's ZIP releases converted to commits. Therefore, nothing stops you or other interested developers from cloning that repository and hacking away. My repo there is by no means "blessed".

So, if I want to contribute to OVP by working on a d3d11 based engine, what do you think is the best way to do that ? Should I work on some advanced features that D3D9Client don't have now(heightmaps for example) or should I work on conversion of some pieces of d3d9client to d3d11 (the same thing you're going to do now) ? And what should I do after I complete something. Merge it with your code from bitbucket and release updated code somewhere ?

I'm pretty sure some parts need a rewrite, but I also think that many things can be directly inherited from the D3D9Client.

BTW, have you already decided how to implement surfaces/textures and blit/fill/create/getdc functions ? In my version of d3d11client I decided to make 2 kinds of textures: First are in the same format as a source image (dxt1,3,5 etc), can have mipmaps and created as resources with immutable usage, and with no miscflags. Second are in B8G8R8A8 format (the only texture format that allows sucessful usage of getdc() ) have no mipmaps, created with default usage and with gdi compatibility miscflag. First type of textures can be used only for rendering. Second can be used for rendering, gdi drawings and blit/fill functions. Any of blit/fill/etc functions checks texture type, and converts any first type texture to second by creating new second type texture with the same dimensions and rendering a textured quad over it. FillColor() functions can be implemented effectively by setting some texture as rendertarget and filling it with ClearRenderTargetView() function (4-5 mcrsec. ). Blit can be implemented by CopySubresourceRegion() (7-8 mcrsec. ) or by rendering a quad in case of a colorkey flag or src == NULL (30-80 mcrsec.). Also, I found that GetDC() and CreateTexture2D()/CreateBuffer() functions are pretty slow (200-600 mcrsec. and 200-500 mcrsec.), so may be it is a good idea to not use them more than it's required.
This approach worked with default, DG3, DG4, XR2 panels without bugs.

 

[Face]

So, if I want to contribute to OVP by working on a d3d11 based engine, what do you think is the best way to do that ?

Well, obviously my idea of developing for OVP is using DVCS with an appropriate hoster. Maybe Martin decides someday that clients should go into the official OVP repository on SVN, but there is no immediate need for this. I'll just put it up and post some notes here and/or in a dedicated thread (if there is something worth of that).
Of course you can also go Jarmonik's way and just put up ZIP archives, it is really up to you.

Should I work on some advanced features that D3D9Client don't have now(heightmaps for example) or should I work on conversion of some pieces of d3d9client to d3d11 (the same thing you're going to do now) ?

Again up to you, but if collaboration is to be maximized, focussing on conversion first might be the clever path.

And what should I do after I complete something. Merge it with your code from bitbucket and release updated code somewhere ?

IMHO, the best way to collaborate with DVCS is to clone the repository, hack your code into the current state of the D3D11Client branch, commit and push it, and send a pull request. Doing so on BitBucket is as follows:

• register, create a fork
• clone to your developer machine, update to D3D11Client
• commit your change(s) - do it in small chunks, commiting is fast with DVCS
• push the changes back to BitBucket and send me a pull request
• keep pulling from me (and/or other developers) and merge in my changes to your branch

BTW, have you already decided how to implement surfaces/textures and blit/fill/create/getdc functions ?

No, I have not decided yet. I will do whatever Jarmo did at first and work my way from there.

regards,
Face

P.S.: If talk about D3D11Client is starting to hijack the thread, a split to another thread might be good.

 

[Glider]

Again up to you, but if collaboration is to be maximized, focussing on conversion first might be the clever path.

Then, I think I will try to start with conversion of some classes of d3d9client to d3d11client and post result here in zip archive with notes about what has been modified and where. May be then I will register at bitbucket. There shouldn't be any problems with testing of modified code, because I already have my working version of d3d11client and can test my code there.
Can I convert SurfaceManager/TileManager (and also add required shaders, samplers etc. into d3d11effect and modify functions that loads planet textures from .tex files) classes first ? I understand how this thing works and already tried to implement it in my version of d3d11client, so I don't think I will have much trouble with it.

 

[Face]

Can I convert SurfaceManager/TileManager (and also add required shaders, samplers etc. into d3d11effect and modify functions that loads planet textures from .tex files) classes first ? I understand how this thing works and already tried to implement it in my version of d3d11client, so I don't think I will have much trouble with it.

Yes, of course, please do so.

 

[Glider]

Yes, of course, please do so.

I've completed TileManager/SurfManager. All relevant code is attached. Also attached compiled dll (VS10, 10_0 feature level, debug config ).

In order to get this working you must do this:
Call TileManager::Globalinit() before any SurfaceManager constructor.
Create SurfaceManager for planet. (obviously)
call SurfaceManager::Render() (with same params that was in D3D7/D3D9 clients)
at every timestep.
TileManager::GlobalExit() will clean memory used for meshes and delete all effect vars.
fog and atmospheric parameters will be calculated within InitRenderTile() function during after SurfaceManager::Render().
Texture loading functions moved to TileBuffer.

 

[Glider]

I've finished conversion of RingManager, HazeManager, CloudManager, CelSphere and CelBackground classes. Now planet and cel. sphere/background code is almost finished (sun, planet markers, dots and bases still not implemented ). Everything should be able to work in 2-threaded mode.

All code for the project and a compiled dll (orbiter sdk101016, release config. require at least DX10.0 compatible video card and OS Vista SP2 or newer) is in attachment.

Now I will add surface bases, D3D11Pad, and Sun.

 

[Moach]

oooh this is gonna be awesome!

may i suggest before anything else, to see if you can make it so that custom fx shaders can be loaded and perhaps even manipulated by addon modules?

i ask this because a lot of what makes DX11 stuff so great is what can be accomplished with GPU programs - would be a shame to restrict addon makers from tapping into that, would it not? :hmm:


the applications range from really cool exhaust flames to mind-blowing volumetric clouds and full-detail seamless terrain (yep, i have done my own experiments on such things, just not for Orbiter use yet)


i dont mean to nag, by all means - carry on with whatever you feel more relevant - i'm just popping ideas off the top of my head here :thumbup:


may the be with you on this undertaking - i know my GTX580 will be too

 

[Face]

Great progress, Glider! I guess until I've finished the conversion, your path is already in gold state :lol: .

I've put up both your code states on my OVP mirror under the D3D11Client branch with the Glider/master bookmark. My changes to make it re-compile under VS 2010 are with the Face/Glider bookmark. My current efforts of conversion are with the extra head without a bookmark.

I'll start to transfer your CelSphere code over to the conversion head, seems like the best thing to do now...

cheers,
Face

BTW: I've tested the re-compiled as well as your original binaries. Both show instability when switching to cockpit view. Sometimes it works, sometimes it CTDs Orbiter. I've yet to investigate why, though...

 

[Glider]

BTW: I've tested the re-compiled as well as your original binaries. Both show instability when switching to cockpit view. Sometimes it works, sometimes it CTDs Orbiter. I've yet to investigate why, though...

I think it happens because PSSetShaderResources( 0, 1, tex->SRV ) at line 116 in Overlay.cpp tries to access SRV when tex pointer doesn't actually point to a texture.(0xdddddddd) if you add " if( TM->Find( tex ) ) " before this line, the CTD should be fixed. (But a texture for 2d panel will be wrong) May be I changed something in Overlay or TextureMgr classes when I was implementing all these managers, because I remember that I never got this CTD before I started conversion of TileManager...

 

[Glider]

New update. Changes: converted D3D11Text, D3D11Pad, D3D11PadFont, D3D11PadBrush, D3D11PadPen, implemented planet sorting from most disant to the nearest, vStar(Sun), surface bases (without shadows for now), dots for distant vessels and planets, non-spheric planets/asteroids, vessel meshes and shadows, vessel/planet/surface markers and debug string (D3D11Pad).

Also: old Overlay class replaced by new one, with more reliable and faster code, fixed bug in TextureMgr when F8 sometimes did CTD, fixed wrong star positions when F9 mode was active. Normal maps implemented, but disabled. AMSO doesn't work (it loads a bunch of triangles instead of mesh), DG4 also can be loaded but not textured. Surface base/vessel Sun lighting is temporarily constant.

Same requirements: OS Vista/Win7 and at least DX10 compatible video card.

I think I can add all missing features in the next update.

 

[Veterok]

I'm seeing D3D11 in the Miscellaneous plugin section, instead of the Graphics engine section. But it works :thumbup:

 

[Glider]

Version 271211. Added:
particle streams, exhausts, vessel and surface base lighting, surface base shadows, local lights, night textures for base buildings, beacons, VCs, configuration file and UI, near plane control, new dots, mesh visibility modes, compatibility with AMSO, reentry stream and billboards, normal maps.

New features: bump, specular and emissive maps. MSAA x2, x4, x8, CSAA x8, x8Q, x16, x16Q anti-aliasing modes (CSAA works only on NVidia cards).

Requirements are same: DirectX 10.0 compatible video card, Vista/Win7/Win8 OS, DirectX newer than June 2010, Orbiter 2010P1.

This version should have all necessary features.

DG4 doesn't work. (it is not compatible with any graphics client)

 

[Veterok]

It's not looking in the Textures2 (or Textures3 etc...) for normal maps. I suspect for other textures as well, but definitely not normals.

I attached normal maps for the Delta Glider Mk4. I did not create these maps, they were originally posted in the D3D9 development thread, by... I forget who. But credit to that guy.

I just saved them as .dds
unzip to "textures/DG" not textures2

Do you want bug reports in this thread, somewhere else, or not at all?

 

[Glider]

It's not looking in the Textures2 (or Textures3 etc...) for normal maps. I suspect for other textures as well, but definitely not normals.

I attached normal maps for the Delta Glider Mk4. I did not create these maps, they were originally posted in the D3D9 development thread, by... I forget who. But credit to that guy.

I just saved them as .dds
unzip to "textures/DG" not textures2

In this version, D3D11Client looks for any vessel textures only in the Textures folder, but I'll add Textures2 support in the next update. Also, there's no need to make normal maps in A8R8G8B8 uncompressed format, because DXT1 also supported and normal maps don't need the alpha channel. I've attached DXT1 versions of DG normal maps to this post.

Do you want bug reports in this thread, somewhere else, or not at all?

Please post them in this thread. Now I know only about these bugs:
- a bug with beacons. (wrong depth)
- small parts of XR2 2d panel appear transparent. (alpha 1.0)
- a bug with animation of Souyz launchpad. (when it starts to rotate)
- planet rings in some scenarios have inverted shadows
I will fix them in the next update, but if you know about any other bugs - post bug report here.

 

[Veterok]

The MFD panels aren't clearing the screen, they just re-write over the previous screen. I noticed my frame rate is over 750fps :tiphat:, could that be related?

 

[Glider]

The MFD panels aren't clearing the screen, they just re-write over the previous screen. I noticed my frame rate is over 750fps :tiphat:, could that be related?

750 fps shouldn't be related. I think you just have good hardware. I'm sure this bug is because of ClearRenderTargetView function (works differently on different systems). I'll replace it by quad rendering in the next update.

 

[Veterok]

Mir and ISS are rendering parts that are in back on top of parts that should be closer to the screen, but only when the view distance drops below about 40m.

 

[asmi]

Hello guys! I was working on my own DX11-based client and until today I had no idea it existed So I took a quick look at the source code and immediately found few issues that I have solved in my client - most important being an issue with processing *.tex files. Here is an essence:
When you're trying to find out a size of the texture in the pack, you use DDSURFACEDESC2::dwLinearSize field, which is wrong. In reality there is no DDSURFACEDESC2 sctructure in DDS files - there is another one called DDS_HEADER. They have the same size, yet certain fields have different meaning. For example in Earth.tex file from the Earth 10-11 lvl package there are quite a few textures which contain multiple mip levels, those tiles will not be processed correctly by the existing code.
I do have a code with that problem fixed and I would be happy to contribute it. So can anyone please explain me what is the process of making changes over there? Shall I ask someone to create a user/branch/whatever in SC? Or I need to send the code somewhere?

Thank you in advance for the answers!

 

[Face]

I do have a code with that problem fixed and I would be happy to contribute it. So can anyone please explain me what is the process of making changes over there? Shall I ask someone to create a user/branch/whatever in SC? Or I need to send the code somewhere?

Well, Glider had the same question, so I made this post. You see, there is really only one "official" OVP source control, and that is Martin's SourceForge SVN repository. I'm not in the position to control what goes there and what not, so I can't tell you anything about it.

As for the development of D3D11Client, I've started a Mercurial repository on Bitbucket here. I try to keep up with Glider's and jarmonik's ZIP-posts, so you can argue that it is a common OVP devel repository there. Since this is a DVCS, you could clone the repository and hack right away on it. But it is certainly not necessary to go all the way to just contribute a few patches. The way Glider and jarmonik put out the code is good enough.

Since it is evident that I can't keep up with actual coding (Glider is doing a tremendous job!), I already felt back to act as repository manager. So just post your code here, I'll take care of putting it into the repo .

regards,
Face

P.S.: Sorry for taking so long to update Glider's master... kids and Xmas, you know...

 

[asmi]

well I did everything as you've described, but the build is failing saying stuff like that:

1>c:\games\orbiter2010dev\orbitersdk\d3d11client\Resources.h(10): fatal error C1083: Cannot open include file: 'Headers\OrbiterAPI.h': No such file or directory
1> CloudManager.cpp
1>c:\games\orbiter2010dev\orbitersdk\d3d11client\Resources.h(10): fatal error C1083: Cannot open include file: 'Headers\OrbiterAPI.h': No such file or directory
1> CSphereMgr.cpp
1>c1xx : fatal error C1083: Cannot open source file: 'CSphereMgr.cpp': No such file or directory

I've checked - that's what's actually in .vcxproj file, but those files don't exist in repo. First files are probably from SDK, so this part is fixable, but what about files like CSphereMgr.cpp? There are quite a number of such files - it looks like project file was not updated for a while...

I've never used Hg before (I'm MS guy - so TFS, and sometimes SVN :tiphat so if you would assist me I'd really appreciate it

---------- Post added at 03:17 AM ---------- Previous post was at 01:03 AM ----------

UPDATE:
OK, whatever it was - I've fixed project file, set up Debug configuration to actually perform a debug build , and set up debugging settings so now if you launch app in debug configuration using VS's "Start Debugging" command - it will launch orbiter and attach to it.
Also fixed mess with missing header files too - btw putting a dozen of classes into one file is a bad idea. I'm a .NET developer and there is a nice convention in C# - one file - one class.
And the last update for today (it's still Tuesday here ) - added "Shaders" vfolder into project and added all shader files there - for ease of use. BTW - what do you guys use for editing shaders? I use this plugin for Visual Studio, which offers nice syntax highlighting. Also I'm going to add shaders compilation step into the build later - just like I did for my own project - it really helps to catch stupid errors like typos without a need to launch app and find out that some shader doesn't work