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 :
Code:
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 ?
Code:
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 :
Code:
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 ?