Project D3D11Client Development

[orb]

Also had to edit the D3D11Cleint.rc file a bit to remove the afxres.h header.

You don't have to. You can instead add an afxres.h file to one of include directories (either to platform SDK's, or to OrbiterSDK's, or to C++'s include directory) with this content.

 

[dumbo2007]

Thanks, will do that. Now I 'll need to figure out what is going wrong while running the client. Does the client compile the shaders or generate atmosphere related tables on first run ?

That still does not explain the crash on later runs though.

Here is the crash log :

**** Orbiter.log
Build Nov  5 2011 [v.111105]
Timer precision: 4.665e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 111105, API 111105]
Module AtmConfig.dll ......... [Build 111105, API 111105]
Module DGConfigurator.dll .... [Build 111105, API 111105]
Module D3D11Client.dll ....... [Build 121201, API 111105]

**** Creating simulation session
Test built Dec  1 2012 is starting up...
D3D11Client::clbkGetViewportSize
D3D11Client::clbkFullscreenMode
Texture not found: Fcd07_n.dds
Texture not found: Fcd07_n.dds
Texture not found: Fcd08_n.dds
Texture not found: Fcd08_n.dds
Texture not found: Fcd09_n.dds
Texture not found: Fcd09_n.dds
Texture not found: Fcd10_n.dds
Texture not found: Fcd10_n.dds
Texture not found: Fcd14_n.dds
Texture not found: Fcd14_n.dds
Texture not found: Fcd15_n.dds
Texture not found: Fcd15_n.dds
Texture not found: Roof01_n.dds
Texture not found: Roof01_n.dds
Texture not found: Roof02_n.dds
Texture not found: Roof02_n.dds
Texture not found: Wall01_n.dds
Texture not found: Wall01_n.dds
Texture not found: Door01_n.dds
Texture not found: Door01_n.dds
Texture not found: Solpanel_n.dds
Texture not found: Solpanel_n.dds
Texture not found: Runway2_n.dds
Texture not found: Runway2_n.dds
Texture not found: Ball_n.dds
Texture not found: Ball_n.dds
Texture not found: Cape17_n.dds
Texture not found: Cape17_n.dds
Texture not found: Cape18_n.dds
Texture not found: Cape18_n.dds
Texture not found: Cape19_n.dds
Texture not found: Cape19_n.dds
Texture not found: Cape20_n.dds
Texture not found: Cape20_n.dds
Texture not found: Cape21.dds
Texture not found: Cape21.dds
Texture not found: Cape21_n.dds
Texture not found: Cape21_n.dds
Texture not found: Cape22_n.dds
Texture not found: Cape22_n.dds
D3D11Client::clbkFullscreenMode
Module Sun.dll ............... [Build 111105, API 111105]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 111105, API 111105]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 111105, API 111105]
Module VenusAtm2006.dll ...... [Build 111105, API 111105]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 111105, API 111105]
Module EarthAtmJ71G.dll ...... [Build 111105, API 111105]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 111105, API 111105]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 111105, API 111105]
Module MarsAtm2006.dll ....... [Build 111105, API 111105]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 111105, API 111105]
Module Jupiter.dll ........... [Build 111105, API 111105]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 111105, API 111105]
Module Europa.dll ............ [Build 111105, API 111105]
Module Ganymede.dll .......... [Build 111105, API 111105]
Module Callisto.dll .......... [Build 111105, API 111105]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 111105, API 111105]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 111105, API 111105]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 111105, API 111105]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module ShuttlePB.dll ......... [Build 111105, API 111105]
Module DeltaGlider.dll ....... [Build 111105, API 111105]
Module LuaInline.dll ......... [Build 111105, API 111105]
Module ShuttleA.dll .......... [Build 111105, API 111105]
Finished initialising status
Finished initialising camera
Finished initialising panels
D3D11Client::clbkGetViewportSize
Finished setting up render state
D3D11Client::clbkPostCreation
Loading Sun...
Loading Jupiter...
Initializing atmosphere (type = 0)...
Initializing terrain...
Searching resources...
Loading Saturn...
Initializing atmosphere (type = 0)...
Initializing terrain...
Searching resources...
Loading Neptune...
Initializing atmosphere (type = 0)...
Initializing terrain...
Searching resources...
Loading Uranus...
Initializing atmosphere (type = 0)...
Initializing terrain...
Searching resources...
Loading Earth...
Initializing atmosphere (type = 2)...
Initializing terrain...
Searching resources...
Loading Alcantara...
Loading Al Anbar...
Loading Baikonur...
Loading Barent Sea...
Loading Cape Canaveral...
Texture not found: Earth_2_w0461_n0160.dds
Texture not found: Earth_2_w0462_n0161.dds
Texture not found: Earth_2_w0461_n0161.dds
Texture not found: Earth_2_w0462_n0162.dds
Texture not found: Earth_2_w0461_n0162.dds
Texture not found: Earth_2_w0462_n0163.dds
Texture not found: Earth_2_w0461_n0163.dds
Texture not found: Earth_2_w0460_n0164.dds
Texture not found: Earth_3_w0920_n0320.dds
Texture not found: Earth_3_w0919_n0320.dds
Texture not found: Earth_3_w0918_n0320.dds
Texture not found: Earth_3_w0917_n0320.dds
Texture not found: Earth_3_w0920_n0321.dds
Texture not found: Earth_3_w0919_n0321.dds
Texture not found: Earth_3_w0918_n0321.dds
Texture not found: Earth_3_w0920_n0322.dds
Texture not found: Earth_3_w0919_n0322.dds
Texture not found: Earth_3_w0918_n0322.dds
Texture not found: Earth_3_w0920_n0323.dds
Texture not found: Earth_3_w0919_n0323.dds
Texture not found: Earth_3_w0918_n0323.dds
Texture not found: Earth_3_w0917_n0323.dds
Texture not found: Earth_3_w0920_n0324.dds
Texture not found: Earth_3_w0919_n0324.dds
Texture not found: Earth_3_w0918_n0324.dds
Texture not found: Earth_3_w0917_n0324.dds
Texture not found: Earth_3_w0920_n0325.dds
Texture not found: Earth_3_w0917_n0325.dds
Texture not found: Earth_3_w0920_n0326.dds
Texture not found: Earth_3_w0919_n0326.dds
Texture not found: Earth_3_w0918_n0326.dds
Texture not found: Earth_3_w0920_n0327.dds
Texture not found: Earth_3_w0919_n0327.dds
Texture not found: Earth_4_w1838_n0650.dds
Texture not found: Earth_4_w1837_n0650.dds
Texture not found: Earth_4_w1836_n0650.dds
Texture not found: Earth_4_w1835_n0650.dds
Texture not found: Earth_4_w1838_n0651.dds
Texture not found: Earth_4_w1837_n0651.dds
Texture not found: Earth_4_w1836_n0651.dds
Texture not found: Earth_4_w1835_n0651.dds

Maybe the problem is with the Earth atmosphere. Perhaps I can change some setting to make it work at least.

 

[Glider]

Now I 'll need to figure out what is going wrong while running the client.

are you sure you use latest 230/231 versions ? I'm sure that 231 worked. 230 also worked for me.

Does the client compile the shaders or generate atmosphere related tables on first run ?

Atmosphere tables generated every time the client is started. Some shaders(those which created through shadermanager's GET_SHADER and GET_SHADER_DEFINES) compiled only on first run. other(which created through D3DX11Compile + CreateShader) compiled and created every time client is started.

Maybe the problem is with the Earth atmosphere. Perhaps I can change some setting to make it work at least.

I don't think that wrong cfg settings of PAS atmosphere can crush it. Anyway all these parameters go into shader.

 

[dumbo2007]

Thanks Glider. I got it running now. The orbiter server wasnt being run with the nvidia card so I was getting a freeze. Now it runs fine. Trying to fix a bug now that I apparently get only on my machine :




These blank textures happen from the 2nd run onwards. I noticed some nulls being loaded while the texture loading was in progress in the splash screen right after Taxiway.dds (or something similar) gets loaded. It passes by too quick so I could not catch it. What part of the code do I change to actually log all the texture loads as they happen ?

 

[Glider]

These blank textures happen from the 2nd run onwards. I noticed some nulls being loaded while the texture loading was in progress in the splash screen right after Taxiway.dds (or something similar) gets loaded. It passes by too quick so I could not catch it.

I can reproduce these black/random textures after 2nd or 3rd start without terminating orbiter process, so it might be a bug. Looks like a null or wrong texture of base mesh but graphics debugger shows correct texture on t0. Also in my case correct texture shows up when I zoom out and wait.

What part of the code do I change to actually log all the texture loads as they happen ?

All textures that are loaded from files except planet textures go through Texture *TextureMgr::LoadTextureFromFile( const char *fname, DWORD flags ) and similar functions for normal/bump/spec/emissive textures. All these textures created with Texture::Texture( TextureMgr * textureMgr, const char *fname, const char *nameWithPath ) constructor. So you can log all textures there.

 

[dumbo2007]

Ok I am adding the debug statements now. Will post the log soon.

Meanwhile how do I start the graphics debugger ? Also what is t0 - level 0 in a mipmap ?

There seems to be 2 texture lists in TextureMgr. A global list of textures in Texture **GList; & a "local" list in Texture **List;

Is there a difference between the 2 and do they need to be kept separate ? Also I noticed that the texture list is actually grown by 256 when textures are added in AddTexture() and by 64 when textures are added in AddGlobalTexture()


Is there a reason why the numbers 256 and 64 were chosen for the local & global texture lists growth amounts respectively ?

void TextureMgr::AddTexture( Texture *tex ) {
	if( Free == ListMax ) {
		Texture **tmp = new Texture *[ListMax+256];
		memset( tmp, 0, sizeof(Texture*)*(ListMax+256) );
		memcpy( tmp, List, sizeof(Texture*)*ListMax );
		delete [ ] List;
		List = tmp;
		ListMax += 256;
	}
	List[Free] = tex;
	Free++;
}

Is it possible to store these textures in a std::map for easily adding without the "grow list" logic and also finding them later ? Currently they are found by traversing the list :

bool TextureMgr::Find( Texture *tex ) {
	if( !tex )			//back buffer always exist
		return true;
	for( DWORD j = 0; j < Free; j++ )
		if( List[j] == tex )
			return true;
	return false;
}

Maybe they can be indexed by the texture pointer Texture*


---------- Post added at 10:27 AM ---------- Previous post was at 10:00 AM ----------

ok, I my question about the 2 lists is answered by the docs for oapi::GraphicsClient::clbkLoadTexture ()

It seems that global textures must be managed by the client & the flags passed in has bit 3 set for this type of texture. The others are managed by Orbiter.

---------- Post added at 10:58 AM ---------- Previous post was at 10:27 AM ----------

So it seems that the pad meshes are loaded after a delay fro the 2nd run onwards. The message that appears in the splash screen says Loading mesh: (null) & its also plainly visible in the screen for the 2 to 3 seconds that it takes to load.

But hmmm it does not happen the 1st time, so it shouldnt happen the 2nd time either. Here is the log. I put in log statements in TextureMgr::LoadTextureFromFile() but that didnt give a clear idea so I logged the D3D11Client:: ProgressString()

**** Orbiter.log
Build Nov  5 2011 [v.111105]
Timer precision: 4.66502e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 111105, API 111105]
Module AtmConfig.dll ......... [Build 111105, API 111105]
Module DGConfigurator.dll .... [Build 111105, API 111105]
Module D3D11Client.dll ....... [Build 121202, API 111105]

**** Creating simulation session
Test - built on Dec  2 2012 is starting up...
Searching for texture:  star.dds
Loading texture :  star.dds
.....
......
Loading Miranda...
Initializing terrain...
Searching resources...
Loading Mimas...
Initializing terrain...
Searching resources...
Loading Proteus...
Initializing terrain...
Searching resources...
Loading Hyperion...
Initializing terrain...
Searching resources...
Loading Nereid...
Initializing terrain...
Searching resources...
Loading Phobos...
Searching for texture:  Phobos.dds
Loading texture &8 :  Phobos.dds
ProgressString :  Loading texture: Phobos.dds
Loading Deimos...
Searching for texture:  Deimos.dds
Loading texture &8 :  Deimos.dds
ProgressString :  Loading texture: Deimos.dds
Loading ISS...
ProgressString :  Loading mesh: (null)
Loading Mir...
ProgressString :  Loading mesh: (null)
Loading Luna-OB1...
ProgressString :  Loading mesh: (null)
Loading PB-01...
Searching for texture:  shuttlepb.dds
Loading texture &8 :  shuttlepb.dds
ProgressString :  Loading texture: shuttlepb.dds
Searching for texture:  shuttlepbwing.dds
Loading texture &8 :  shuttlepbwing.dds
ProgressString :  Loading texture: shuttlepbwing.dds
Loading GL-01...
ProgressString :  Loading mesh: (null)
ProgressString :  Loading mesh: (null)
Loading GL-NT...
ProgressString :  Loading mesh: (null)
ProgressString :  Loading mesh: (null)
Loading SH-02...
ProgressString :  Loading mesh: (null)
ProgressString :  Loading mesh: (null)
Loading GL-02...
ProgressString :  Loading mesh: (null)
ProgressString :  Loading mesh: (null)
D3D11Client::clbkCloseSession
D3D11Client::clbkDestroyRenderWindow
**** Closing simulation session

Maybe the meshes do get loaded for the pads. But they are not displayed. Trying to find out where I can put a log line to confirm that the pad meshes are getting loaded.

 

[Glider]

Meanwhile how do I start the graphics debugger ? Also what is t0 - level 0 in a mipmap ?

debug->graphics->start diagnostics. t0 is texture at slot 0 (in pixel shader when base meshes is rendered). like Texture2D texture : register( t0 ); which means it can be set there with PSSetShaderResources( 0, 1, &srv );

Is there a reason why the numbers 256 and 64 were chosen for the local & global texture lists growth amounts respectively ?

It is 256 and 64 only because they are round numbers and big enough not to cause reallocation often.

Is it possible to store these textures in a std::map for easily adding without the "grow list" logic and also finding them later ? Currently they are found by traversing the list :

Yes, of course it is possible to replace this reinvented wheel with STL container like std::map or std::vector. Actually a lot of things in TextureMgr should be changed and removed. Like that multithreading thing that was written about a year ago (those queues and _blit etc. functions). Good idea for multithreading would be to create 2-3 deferred context and render things like vessels, planet terrain, overlay and terrain tiles from generator at the same time after oapi::GraphicsClient::Render() was called and then execute commmand lists (anyway the heaviest part of orbiter with an attached graphics client is the graphics client). So this 2d thing can be made simple without any queues.

So it seems that the pad meshes are loaded after a delay fro the 2nd run onwards. The message that appears in the splash screen says Loading mesh: (null) & its also plainly visible in the screen for the 2 to 3 seconds that it takes to load.

Loading mesh: (null) is from Vessel constructor. After it loads a mesh it is supposed to show Loading mesh: <mesh file name> but mesh name always null. These "Loading mesh: (null)" lines always there - it is probably just name of mesh that is always null. Anyway meshes are where they should. Problem is with texture.

Maybe the meshes do get loaded for the pads. But they are not displayed. Trying to find out where I can put a log line to confirm that the pad meshes are getting loaded.

I'm sure pad meshes are loaded correctly. It is texture that doesn't work immediatelly after 2nd start. You can see it on screenshot - there's a black mesh which is black because it doesn't have texture at 0 slot in pixel shader or that texture isn't shown by some reason.

 

[Poscik]

Hi, have some problem when using "Compute shaders" mode.
View attachment 10932

Also when using Pixel Shader mode, atmosphere looks little bit scary...
View attachment 10934
View attachment 10933

Anyone got this?

I have GeForce GTS450, and if It is important Pentium D 925 (yeah, still ;d). Forceware is 301.42, Win7 x64.

[EdiT]
Checked also on i5, GTX660. The same happens.

And what about this?

 

[dumbo2007]

I'm sure pad meshes are loaded correctly. It is texture that doesn't work immediatelly after 2nd start. You can see it on screenshot - there's a black mesh which is black because it doesn't have texture at 0 slot in pixel shader or that texture isn't shown by some reason.

Yeah you are right. The texture gets loaded after a delay. I wonder if it could have something to do with distance of the pad from the camera - some kind of level of detail setting ?

I am trying to understand the rendering process at the moment. So I guess there are 2 threading modes for the renderer. In single threaded mode (cfg->RThread = false) , the sequence of function calls is like this :

                SC->SaveParams();
		SC->Update();

		SC->Render_0();
		SC->Render_1();
		SC->Render3DCompleted();
		if (m_displayHUD)
		{
			OV->RenderPBuffer();

			Render2DOverlay();
                  }

So in single threaded mode there is a check if HUD should be displayed and only then do the 2d overlay stuff. Why is there no check in multi-threaded mode as well ?

                WaitForSingleObject( FrameReady, INFINITE );
		ResetEvent( FrameReady );
		if( sscreen_init )	ExitSplashScreen();

		SC->SaveParams();
		Render2DOverlay();

--------------------------------------------


Continuing with the rendering part, so the other mode - multithreaded rendering - that has just 2 threads right ?

1 rendering thread : for 3D stuff
1 main thread where all the callbacks execute : also draws 2D overlays


The rendering thread finishes seems to have 2 parts:

SC->Render_0();

Signals completion using SetEvent( FrameReady )

lets the main thread do its 2D overlay stuff & signal completion using UpdateReady

then back in rendering thread execute :

SC->Render_1();

Not sure why the 2D stuff could not have been done after the calls to :

SC->Render_0();
SC->Render_1();

as in single threaded mode.



---------- Post added at 11:41 PM ---------- Previous post was at 11:27 PM ----------

Also a question about the 2D drawing part. So the 2D stuff is always drawn last. But the texture updation etc can be done before that and the required data stored within object member variables (the ones defined as protected in the class declaration). This seems to be initiated by :

SC->SaveParams();

Is that why this function is called "SaveParams" ? I noticed this is a common convention used throughout the code for many different classes which can have 2D overlays that need to be drawn later.

eg. in various places there is :

AtmM->SaveParams();
TerM->SaveParams( &mWorld, dist_scale, patchres, 0.0, bFog );

CB->SaveParams( 8, BgLvl ); (celestial background)

The information stored can be used to draw over the 3D scene later by calling Render2DOverlay() which calls clbkRender2DPanel()

Was this the general idea ?

---------- Post added at 11:53 PM ---------- Previous post was at 11:41 PM ----------

Furthermore, there are 2 main functions for rendering in the Scene class :

Scene::Render_0 : Is for celestial sphere & constellations > stars > vessel shadows > planets(& bases they contain) > planet markers > surface markers in that order
Scene::Render_1 : Is for vessels

Is that correct ?

So Render_0 is responsible for rendering the base structures like the landing pad, buildings etc through calling :

vPlanet::Render() > Base[j]->RenderStructuresBS(); > structs_bs[j]->Render() & structs_as[j]->Render() (before & after shadows - I am not sure why there has to be 2 such mesh renders)

So the problem is probably in D3D11Mesh::Render() is where I can see that mesh visibility & culling happens. Still figuring this out.

I am wondering why vessel shadows are not hidden/drawn over when planets & planet markers are drawn above them. Maybe they are drawn to a separate shadow buffer ?!

In Scene::Render_1() I see this line :

//=======================================================================================================
// Vessels: Shadows -> Meshes -> Beacons -> Exhaust -> Particle Streams -> Markers
//=======================================================================================================

Are vessel shadows rendered again here ?



---------- Post added 05-12-12 at 12:10 AM ---------- Previous post was 04-12-12 at 11:53 PM ----------

Regarding the deferred rendering, I could probably start with moving Scene::Render_1() to a different context.

...and then execute commmand lists

So by the command lists you mean the DirectX primitive drawing deferred command list generated by each rendering thread ?

Or the sketchpad commands as added & executed by :

void TextureMgr::AddToCommandList( DWORD type, Data *data ) {
	if( CommandCount == CommandMax ) {
		Command *tmp = new Command [CommandMax+32];
		ZeroMemory( tmp, sizeof(Command)*(CommandMax+32) );
		memcpy( tmp, CList, sizeof(Command)*CommandMax );
		delete [ ] CList;
		CList = tmp;
		CommandMax += 32;
	}

	CList[CommandCount].type = type;
	memcpy( &CList[CommandCount].params, data, sizeof(Data) );
	CommandCount++;
}

void TextureMgr::ExecuteCommandList() {

	for( DWORD j = 0; j < CommandCount; j++ ) {
		
		switch( CList[j].type ) {
		case 0:
			_CopyBitmap( &CList[j].params );
			break;
		case 1:
			_FillSurface1( &CList[j].params );
			break;
		case 2:
			_FillSurface2( &CList[j].params );
			break;
		case 3:
			_Blit1( &CList[j].params );
			break;
		case 4:
			_Blit2( &CList[j].params );
			break;
		case 5:
			_ScaleBlit( &CList[j].params );
			break;
		case 6:
			_ConvertToSurface( &CList[j].params );
			break;
		}
	}

	ZeroMemory( CList, sizeof(Command)*CommandMax );
	CommandCount = 0;
}

I guess even the sketchpad command list execution can be moved to a separate thread as you suggested. Where exactly is this queue you were talking about ?

 

[Glider]

Yeah you are right. The texture gets loaded after a delay. I wonder if it could have something to do with distance of the pad from the camera - some kind of level of detail setting ?

Yes, looks like some problem with level of detail but the only level of detail that textures have is mipmaps which controlled outside of client. (Client only defines number of mips and filters)

I am trying to understand the rendering process at the moment. So I guess there are 2 threading modes for the renderer. In single threaded mode (cfg->RThread = false) , the sequence of function calls is like this :

There's only single-threaded mode and remains of wrong multithreaded mode this client had a year ago. So everything that is about multithreading in current code isn't used.

So in single threaded mode there is a check if HUD should be displayed and only then do the 2d overlay stuff. Why is there no check in multi-threaded mode as well ?
1 rendering thread : for 3D stuff
1 main thread where all the callbacks execute : also draws 2D overlays

Yes, it was supposed to be 2-threaded mode with one thread for orbiter and oapi calls (saveparams supposed to work with main thread) + one thread for 3D stuff (update and render works from that thread). "FrameReady" event signals completion of frame by rendering thread, "UpdateReady" signals completion of saving parameters and calling all oapi functions required for rendering. That mode worked in first versions of client but later (after asmi joined the project) it was forgotten and never used or updated anymore. Now I'm sure it should be removed from client completely because it obviously complicates code too much and was coded in a wrong way.

Also a question about the 2D drawing part. So the 2D stuff is always drawn last. But the texture updation etc can be done before that and the required data stored within object member variables (the ones defined as protected in the class declaration). This seems to be initiated by :
SC->SaveParams();
Is that why this function is called "SaveParams" ?

These functions called "SaveParams" because in that multithreaded mode it was supposed to work from main thread and save every data from orbiter that's required for rendering.

Furthermore, there are 2 main functions for rendering in the Scene class :

Scene::Render_0 : Is for celestial sphere & constellations > stars > vessel shadows > planets(& bases they contain) > planet markers > surface markers in that order
Scene::Render_1 : Is for vessels

Is that correct ?

Yes. Render_0 was supposed to work before SaveParams was called and was used for rendering of base structs/planets/backround etc. except vessels. Render_1 worked after update of positions/matrixes etc. and was used for vessels.

So the problem is probably in D3D11Mesh::Render() is where I can see that mesh visibility & culling happens. Still figuring this out.

Mesh and mesh group culling has nothing to do with this problem becuse obviously meshes are culled correctly. Problem with texture has nothing to do with mesh culling.

I am wondering why vessel shadows are not hidden/drawn over when planets & planet markers are drawn above them. Maybe they are drawn to a separate shadow buffer ?!

Actually shadows for vessels and base structs are drawn into shadow map texture(4096x4096 with format 32-bit FLOAT format) which used later as shader resource when planet tiles are rendered. (it is cascaded shadow map with 4 cascades)

Are vessel shadows rendered again here ?

Vessel ans base shadows are rendered only once into shadow map in Render_0 before planets are rendered. That lines remains from flat shadows which was the type of shadows the client used before shadow maps was added. (flat shadows was done in the same way they were in DX7/DX9 clients but obviously they was incompatible with terrain.(terrain is never flat while that "old" shadows always were flat)

Regarding the deferred rendering, I could probably start with moving Scene::Render_1() to a different context.

Please don't make such changes (at least in public version) now because client currently doesn't need multithreaded rendering (beacuse fps is usually very good). I only meant that somewhere in the future multithreading can be implemented by using deferred rendering for different types of objects. I didn't want to say it is what should be done right now. Also implementation of proper multithreading will require serious rewrite of some parts of code and you shouldn't start it right now. Though you can do whatever you want with your local copy of code, of course.

So by the command lists you mean the DirectX primitive drawing deferred command list generated by each rendering thread ?

I mean D3D command lists used in ID3D11DeviceContext::FinishCommandList() ExecureCommandList(). Not those remains of client's multithreaded mode that should be removed.

So really this client has no working multithreading right now and no multithreading is required now. Forget about multithreading for now.

And what about this?

Only asmi should tell you what is going on in the first screenshot, since it is he who made post-processing in the client. But in the second and third screenshot everything looks ok. Sun is so ugly in 2nd screenshot because of a functoin in the atmosphere shader code that draws a white circle for sun (which was taken from Bruneton's samples as it was there. I think it should be disabled because that sun obviously looks incorrect at high altitudes).

 

[dumbo2007]

Ok thats good to hear, about the single threading working great. Thanks for taking the time to give detailed answers

Yeah I am not about to start putting in threading. Its too complex for me at my current level of understanding of DirectX

What I am focused on right now is clearing out un-needed code (all in my local copy, not to worry !!) and then to understand why the texture issue is happening. After that I ll move on to using maps for some of the lists in the client and if I see any improvement only then will I even think of making it public

So in an attempt to understand whats happening exactly with that texture on Brighton, I am removing code from the client till only planet rendering is left. I just want to draw Brighton Beach and the pads. I am guessing for this I can remove GDIPad, PostProcessingPipeline related files, Cloud Manager, Particle Stream, noise crater, TMesh, Ring Manager, PStream, VStar, Atmosphere, AdvancedAtmosphere, BasicAtmosphere and Terrain* files ?

None of these have anything(hopefully!) to do with the issue directly though I ll keep checking the scenario each time I clear out something.

 

[Glider]

So in an attempt to understand whats happening exactly with that texture on Brighton, I am removing code from the client till only planet rendering is left. I just want to draw Brighton Beach and the pads. I am guessing for this I can remove GDIPad, PostProcessingPipeline related files, Cloud Manager, Particle Stream, noise crater, TMesh, Ring Manager, PStream, VStar, Atmosphere, AdvancedAtmosphere, BasicAtmosphere and Terrain* files ?

:blink: I think it is a "bit" too much to remove 2/3 of client's files in order to disable some parts from being rendered. Also it will consume a lot of time and most likely give no result. Why don't you want to use C++ comments to disable some calls or #define something and then use #if end #endif to "comment" large amounts of code ? And none of these parts probably doesn't have anything to do with the problem you want to fix.

 

[dumbo2007]

Yeah I have dumbed down the Render_0() function now to this and still get the same texture missing on 2nd run :

void Scene::Render_0() {
	DWORD j;

	int distcomp( const void *arg1, const void *arg2 );	//compares object by their distance from camera

	D3DXCOLOR ClearColor( cBackground.x, cBackground.y, cBackground.z, 0.0f );

	{
		iCtx->ClearRenderTargetView( RTarget_RTV, ClearColor );
	}
	iCtx->ClearDepthStencilView( RTarget_DSV, D3D11_CLEAR_DEPTH | D3D11_CLEAR_STENCIL, 1.0f, 0 );
	SetRenderTarget();

	iCtx->OMSetDepthStencilState( DSS_NoDepth_NoStencil, 0 );

	D3D11_VIEWPORT VP;
    VP.Width = (FLOAT)cfg->cWidth;
    VP.Height = (FLOAT)cfg->cHeight;
    VP.MinDepth = 0.0f;
    VP.MaxDepth = 1.0f;
    VP.TopLeftX = 0;
    VP.TopLeftY = 0;
	iCtx->RSSetViewports( 1, &VP );

#if _DEBUG
	D3DPERF_BeginEvent(D3DCOLOR_ARGB(0xFF, 0, 0, 0x20), L"Vessels: Shadow map");
#endif
	iCtx->OMSetRenderTargets(0, nullptr, mainShadowMap_DSV);

	iCtx->ClearDepthStencilView(mainShadowMap_DSV, D3D11_CLEAR_DEPTH, 1.0f, 0);

	iCtx->OMSetDepthStencilState( mainShadowMapDSS, 0 );
	iCtx->RSSetState(mainShadowMapRS);

	cb_PS_Shadow shadowMapArgs;
	shadowMapArgs.sunDirection = D3DXVECTOR4(sunDirection.x, sunDirection.y, sunDirection.z, 0);
	shadowMapArgs.shadowMapRefPoint = D3DXVECTOR4(shadowReferencePoint.x, shadowReferencePoint.y, shadowReferencePoint.z, 0);
	shadowMapArgs.ShadowVP[0] = shadowVP[0];
	shadowMapArgs.ShadowVP[1] = shadowVP[1];
	shadowMapArgs.ShadowVP[2] = shadowVP[2];
	shadowMapArgs.ShadowVP[3] = shadowVP[3];
	iCtx->UpdateSubresource(vVessel::cb_ps_ShadowMap, 0, nullptr, &shadowMapArgs, 0, 0);


	
#if _DEBUG
	D3DPERF_EndEvent();
#endif

	SetRenderTarget();

	//================================================
	//				Planets and stars(Sun)
	//================================================
	//fill planet list with planets if they are close enough to camera:
	UINT np = 0;
	for( j = 0; j < GObjCount; j++ ) {
		if( GObject[j].vobj->GetAppRadius() < 0.01 && GObject[j].type != OBJTP_STAR )
			continue;
		PLIST[np].cdist = GObject[j].vobj->GetCDist();
		PLIST[np].vo = GObject[j].vobj;
		PLIST[np].type = GObject[j].type;
		np++;
	}

	//sort list...
	qsort( (void*)PLIST, np, sizeof(CELOBJ), distcomp );

	//render distant dots first
#if _DEBUG
	D3DPERF_BeginEvent(D3DCOLOR_ARGB(0xFF, 0, 0, 0x20), L"Celestial bodies");
#endif

	//render nearest planets and planet markers
	for( j = 0; j < np; j++ ) {
		bool active = PLIST[j].vo->active;

		if( active || PLIST[j].type == OBJTP_STAR )	
		{			
			iCtx->PSSetShaderResources(11, 1, &mainShadowMap_SRV);
			iCtx->PSSetSamplers(3, 1, &ssMainShadowMap);
			PLIST[j].vo->Render();
			ID3D11ShaderResourceView * emptySRV[] = { nullptr };
			iCtx->PSSetShaderResources(11, 1, emptySRV);
			iCtx->PSSetConstantBuffers(3, 1, &vVessel::cb_ps_ShadowMap);
		}

	}
#if _DEBUG
	D3DPERF_EndEvent();
#endif
}

It seems to appear faster now - sometimes after 3 secs , sometimes after 7 secs. I ll see if I can hack more stuff away. Seems that's the most I can remove in this function. I ll start removing stuff in PLIST[j].vo->Render() now, sigh!!

---------- Post added at 12:16 AM ---------- Previous post was at 12:03 AM ----------

oh !! vPlanet::Render() is huge !!

---------- Post added at 02:31 PM ---------- Previous post was at 12:16 AM ----------

Regarding the vertex positions of various objects set in the vertex buffers, as I see it there are 2 ways to draw things :

1. If the Sun is at position 0,0,0 in global co-ordinates & the celbody closest to camera is at 1000, 1000, 1000 (global co-odinates) then we can directly send 1000, 1000, 1000 to GPU. If the camera is at 1100, 1100, 1100 then we can place the camera there.

2. Or we can translate everything towards the origin & send 0,0,0 to the GPU for drawing the planet & put the camera at 100,100,100. The sun is at -1000, -1000, -1000 then & still far away.

So the 1st method sends the simulation co-ordinates directly to the GPU. The 2nd method has a difference between simulation & rendering co-ordinates. Which method does the D3D11 client use ? Does it make any difference if lower floating point values are used while rendering ?

---------- Post added at 09:07 PM ---------- Previous post was at 02:31 PM ----------

Reduced vPlanet::Render to this :

//================================================
//			Render
//================================================

void vPlanet::Render() 
{
	DWORD j;

	if( !active )		return;
	if( patchres == 0 ) return;

	bool fog = bFog;

	DWORD bg_color = SC->GetBgColor();
	bool add_ambient = ((bg_color & 0xFFFFFF) && (obj != SC->GetProxyBody()));

	if( !PlanetMesh ) {
		if( nbase ) {

			
#if _DEBUG
		D3DPERF_BeginEvent(D3DCOLOR_ARGB(0xFF, 0, 0x40, 0x40), L"RenderStructuresBS");
#endif
			D3D11Mesh::InitRender();
			for( j = 0; j < nbase; j++ )		//render base structures before shadows
				Base[j]->RenderStructuresBS();
#if _DEBUG
		D3DPERF_EndEvent();
#endif

	

		}
	}

}

Still getting the same texture issue. Only the landing pads are rendered now (& other base structures)

 

[tonnyrat]

Can anyone PM me the links to the 3D/HiRes textures/heightmaps? I PM'd asmi a few weeks ago with no response so I imagine he is very busy.

 

[Veterok]

Can anyone PM me the links to the 3D/HiRes textures/heightmaps? I PM'd asmi a few weeks ago with no response so I imagine he is very busy.

I'm not sure where the heightmaps are, but some highres textures and normal maps are linked in this thread.
http://orbiter-forum.com/showthread.php?p=335032&postcount=28

 

[Astronut25]

IIRC, a few pages back ASMI said that he didn't want the heightmaps to be distributed yet because the format was not finalised yet, but if you really want to try it out, just PM him (thats what he said). I'm not sure if it would be okay for me to post the links because of that.

One more thing, I can't seem to get Mars' heightmap to work, and anything I do to test whether its the file thats messed up just causes orbiter to act strangely.

 

[eddievhfan1984]

Install issue

Installation issue: whenever I enable the D3D11 module, an error message comes up, as the attached image describes...

Help?

 

[orb]

Installation issue: whenever I enable the D3D11 module, an error message comes up, as the attached image describes...

What version of Orbiter are you using - beta 111105, which is required, or 100830? Wind isn't present in yours, so it's some pre-110822.

(The modification date of orbiter.exe and orbiter_ng.exe files, as shown on the image, doesn't tell much, because it was probably set to the date of installation/extraction.)

 

[Screamer7]

I have a problem I can't solve.
When I run the D3D11 client, everything works normally.
I choose the XR2 scenario, take off from Cape Canaveral to ISS scenario.
I took off normally and use the XR2 autopilot to assist me with the ascend.
At about mach 4 I open the scram doors and at mach 5 I engage the scram engines.
My ascend run nominally until sudden at about 5 minutes into the ascend I get a CTD.
I tried it numerous times, with the same result.
I even tried other bases and the same happens.
This CTD do not happen with the D3D9 client, only with the D3D11 client.
That is why I post it here.
Here is my Orbiter log file:

**** Orbiter.log
Build Nov 5 2011 [v.111105]
Timer precision: 3.19685e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 111105, API 111105]
Module AtmConfig.dll ......... [Build 111105, API 111105]
Module DGConfigurator.dll .... [Build 111105, API 111105]
Module D3D11Client.dll ....... [Build 120603, API 111105]
Module CustomMFD.dll ......... [Build 111105, API 111105]
Module ScnEditor.dll ......... [Build 111105, API 111105]
Module ExtMFD.dll ............ [Build 111105, API 111105]
Module Framerate.dll ......... [Build 111105, API 111105]
Module FlightData.dll ........ [Build 111105, API 111105]
Module Rcontrol.dll .......... [Build 111105, API 111105]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module AeroBrakeMFD.dll ...... [Build ******, API 100830]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module InterMFD55.dll ........ [Build 100826, API 100704]
Module uap.dll ............... [Build 110613, API 100830]

**** Creating simulation session
D3D11Client - version RC34.90, built Jun 3 2012 is starting up...
D3D11Client::clbkGetViewportSize
D3D11Client::clbkFullscreenMode
Texture not found: Fcd07_n.dds
Texture not found: Fcd07_n.dds
Texture not found: Fcd08_n.dds
Texture not found: Fcd08_n.dds
Texture not found: Fcd09_n.dds
Texture not found: Fcd09_n.dds
Texture not found: Fcd10_n.dds
Texture not found: Fcd10_n.dds
Texture not found: Fcd14_n.dds
Texture not found: Fcd14_n.dds
Texture not found: Fcd15_n.dds
Texture not found: Fcd15_n.dds
Texture not found: Roof01_n.dds
Texture not found: Roof01_n.dds
Texture not found: Roof02_n.dds
Texture not found: Roof02_n.dds
Texture not found: Wall01_n.dds
Texture not found: Wall01_n.dds
Texture not found: Door01_n.dds
Texture not found: Door01_n.dds
Texture not found: Solpanel_n.dds
Texture not found: Solpanel_n.dds
Texture not found: Runway2_n.dds
Texture not found: Runway2_n.dds
Texture not found: Ball_n.dds
Texture not found: Ball_n.dds
Texture not found: Cape17_n.dds
Texture not found: Cape17_n.dds
Texture not found: Cape18_n.dds
Texture not found: Cape18_n.dds
Texture not found: Cape19_n.dds
Texture not found: Cape19_n.dds
Texture not found: Cape20_n.dds
Texture not found: Cape20_n.dds
Texture not found: Cape21.dds
Texture not found: Cape21.dds
Texture not found: Cape21_n.dds
Texture not found: Cape21_n.dds
Texture not found: Cape22_n.dds
Texture not found: Cape22_n.dds
D3D11Client::clbkFullscreenMode
Module Sun.dll ............... [Build 111105, API 111105]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 111105, API 111105]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 111105, API 111105]
Module VenusAtm2006.dll ...... [Build 111105, API 111105]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 111105, API 111105]
Module EarthAtmJ71G.dll ...... [Build 111105, API 111105]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 111105, API 111105]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 111105, API 111105]
Module MarsAtm2006.dll ....... [Build 111105, API 111105]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 111105, API 111105]
Module Jupiter.dll ........... [Build 111105, API 111105]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 111105, API 111105]
Module Europa.dll ............ [Build 111105, API 111105]
Module Ganymede.dll .......... [Build 111105, API 111105]
Module Callisto.dll .......... [Build 111105, API 111105]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 111105, API 111105]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 111105, API 111105]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 111105, API 111105]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module XR2Ravenstar.dll ...... [Build 120513, API 100830]
Module ShuttleA.dll .......... [Build 111105, API 111105]
Module ShuttlePB.dll ......... [Build 111105, API 111105]
Module DeltaGlider.dll ....... [Build 111105, API 111105]
Module LuaInline.dll ......... [Build 111105, API 111105]
Finished initialising status
Finished initialising camera
D3D11Client::clbkGetViewportSize
D3D11Client::clbkGetViewportSize
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiBlt
Colour key argument not supported by graphics client
---------------------------------------------------------------
Finished initialising panels
D3D11Client::clbkGetViewportSize
Finished setting up render state
D3D11Client::clbkPostCreation
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::GetHorizonAirspeedVector
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::GetShipAirspeedVector
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------


I noticed there is several missing textures in it, but do not know how to fix them.
Any suggestions?
Thanks.

 

[orb]

I noticed there is several missing textures in it, but do not know how to fix them.
Any suggestions?
Thanks.

They are not the cause of the problem. Read some posts earlier in this thread - the case of "missing" textures is explained and they don't cause any problem, it's a part of base textures feature (night textures).