Current_Render and Fog fixes by Sikkpin on Doom3 World

[New Horizon]

Thought this could be of interest to the Mod in a future release. Some nice fixes.

 

http://www.doom3world.org/phpbb2/viewtopic.php?t=25444

[Bikerdude]

Just bloody awesome, has anyone asked him if he would like to help with TDM..?

 

Some slick sun shafts:

 

 

Some cool water edge effect:

 

A bloody cool fog effect: (this can can allow for fogging inside the skybox)

 

Imagine if we had "The caduceus of St Alban" or "The Lich-Queen" setup like this -

 

Man... we need water like this:

[Obsttorte]

The questions are as always:

• How much effort is needed for implementation?
  
• How high is the impact on game performance?
  

But it is definetely cool in regards to the fact that this engine is almost ten years old.

 

Personally I like how the water looks in TDM. What would be nice is if the reflective water shader would have a lower impact on performance, as it is currently almost unusable. Also having an alternative fog would be great. The current way it works is just annoying.

[New Horizon]

The previous stuff done in the thread would be far too performance intensive and would also require remaking all of our textures, I was only suggesting the 'current_render' and fog fixes since they would work with our existing assets. JC Denton or Rebb could have implemented all of the high level visual doohickery, but we chose to go with our current 'lite' settings.

[Bikerdude]

So no chance of getting any of the effects in my screenshots above..?

[Sotha]

MM.. I would just be happy if we had fog improvement.

And of course water improvement. At present our water effect affects the surfaces that are not IN the water. Looks unnatural.

[New Horizon]

So no chance of getting any of the effects in my screenshots above..?

 

Maybe some stuff, but we intentionally went with our current HDR-Lite due to the rather large performance hit, compatibility issues, and that it really changed the look of the Mod far too much.

Light shafts might be possible, I'm not sure, but I wouldn't want to have to reopen the whole HDR can of worms to get them. lol

 

MM.. I would just be happy if we had fog improvement.

And of course water improvement. At present our water effect affects the surfaces that are not IN the water. Looks unnatural.

 

Yeah, Fog and the whole render buffer issue would be great to have fixed.

[Springheel]

That water is pretty damn impressive.

[nbohr1more]

Source Code which contains some of these fixes:

 

(rehosted at my dropbox. the original links in the thread still work for now...)

 

https://dl.dropboxusercontent.com/u/17706561/breadcrumbs_src_31-10-13.7z

 

Thread:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=8&p=250746

[nbohr1more]

Interaction.cpp

 

// generate a lighted surface and add it
	if ( shader->ReceivesLighting() || lightShader->IsFogLight() ) {	// sikk - fogLight fix: added "|| lightShader->IsFogLight()" - ambient surfaces are now fogged
		if ( tri->ambientViewCount == tr.viewCount && !lightShader->IsFogLight()) {	// sikk - fogLight fix: "&& !lightShader->IsFogLight()" - this keeps lit surfaces from fogging twice (or at least being created twice...I think)
			sint->lightTris = R_CreateLightTris( entityDef, tri, lightDef, shader, sint->cullInfo );
		} else {
			// this will be calculated when sint->ambientTris is actually in view
			sint->lightTris = LIGHT_TRIS_DEFERRED;
		}
		interactionGenerated = true;
	}

 

	// there will only be localSurfaces if the light casts shadows and
				// there are surfaces with NOSELFSHADOW
				if ( sint->shader->Coverage() == MC_TRANSLUCENT && !vLight->lightShader->IsFogLight() ) {	// sikk - fogLight fix: allow translucent surfaces to fog (they only fog properly of they write to the depth buffer which, for now, is only water surfaces)
					R_LinkLightSurf( &vLight->translucentInteractions, lightTris,
						vEntity, lightDef, shader, lightScissor, false );
				} else if ( !lightDef->parms.noShadows && sint->shader->TestMaterialFlag(MF_NOSELFSHADOW) ) {
					R_LinkLightSurf( &vLight->localInteractions, lightTris,
						vEntity, lightDef, shader, lightScissor, false );
				} else {
					R_LinkLightSurf( &vLight->globalInteractions, lightTris,
						vEntity, lightDef, shader, lightScissor, false );
				}
			}
		}
	}

 

So that looks like the fog fix...

 

Not sure what else might need to be done but I know he has this whole funky culling\LOD system for lights(!) and some new per location Ambient Light behaviors

so this may be dependent on that code. Will have to compare...

Edited November 21, 2013 by nbohr1more

[nbohr1more]

Current Render fix?

 

draw_common.cpp

 

=====================
RB_STD_DrawShaderPasses

Draw non-light dependent passes
=====================
*/
int RB_STD_DrawShaderPasses( drawSurf_t **drawSurfs, int numDrawSurfs ) {
   int i;

   // only obey skipAmbient if we are rendering a view
   if ( backEnd.viewDef->viewEntitys && r_skipAmbient.GetBool() ) {
       return numDrawSurfs;
   }

   RB_LogComment( "---------- RB_STD_DrawShaderPasses ----------\n" );

   // if we are about to draw the first surface that needs
   // the rendering in a texture, copy it over
   if ( drawSurfs[0]->material->GetSort() >= SS_POST_PROCESS ) {
       if ( r_skipPostProcess.GetBool() ) {
           return 0;
       }

       // only dump if in a 3d view
       // sikk - We are capturing the current render for each surface that needs it and post processes
       // are capturing it manually
       //if ( backEnd.viewDef->viewEntitys && tr.backEndRenderer == BE_ARB2 ) {
       //    globalImages->currentRenderImage->CopyFramebuffer( backEnd.viewDef->viewport.x1, backEnd.viewDef->viewport.y1,
       //        backEnd.viewDef->viewport.x2 - backEnd.viewDef->viewport.x1 + 1,
       //        backEnd.viewDef->viewport.y2 - backEnd.viewDef->viewport.y1 + 1, false );
       //}
       backEnd.currentRenderCopied = true;
   }

   GL_SelectTexture( 1 );
   globalImages->BindNull();

   GL_SelectTexture( 0 );
   qglEnableClientState( GL_TEXTURE_COORD_ARRAY );

   RB_SetProgramEnvironment();

   // we don't use RB_RenderDrawSurfListWithFunction()
   // because we want to defer the matrix load because many
   // surfaces won't draw any ambient passes
   backEnd.currentSpace = NULL;

   for ( i = 0; i < numDrawSurfs; i++ ) {
       if ( drawSurfs[i]->material->SuppressInSubview() ) {
           continue;
       }

       if ( backEnd.viewDef->isXraySubview && drawSurfs[i]->space->entityDef ) {
           if ( drawSurfs[i]->space->entityDef->parms.xrayIndex != 2 ) {
               continue;
           }
       }

// ---> sikk - Material needs _currentRender
       // we need to draw the post process shaders after we have drawn the fog lights
       //if ( drawSurfs[i]->material->GetSort() >= SS_POST_PROCESS && !backEnd.currentRenderCopied ) {
       //    break;
       //}

       // I'm assuming here that all materials with a sort order >= SS_POST_PROCESS
       // is an actual post process and manually captures the current render
       if ( drawSurfs[i]->material->NeedsCurrentRender() && drawSurfs[i]->material->GetSort() < SS_POST_PROCESS ) {
           // only dump if in a 3d view
           if ( backEnd.viewDef->viewEntitys && tr.backEndRenderer == BE_ARB2 ) {
               globalImages->currentRenderImage->CopyFramebuffer( backEnd.viewDef->viewport.x1, backEnd.viewDef->viewport.y1,
                   backEnd.viewDef->viewport.x2 - backEnd.viewDef->viewport.x1 + 1,
                   backEnd.viewDef->viewport.y2 - backEnd.viewDef->viewport.y1 + 1, false );
           }
       }
// <--- sikk - Material needs _currentRender

       RB_STD_T_RenderShaderPasses( drawSurfs[i] );
   }

   GL_Cull( CT_FRONT_SIDED );
   qglColor3f( 1, 1, 1 );

   return i;
}

[Serpentine]

I want to look at this stuff once things are more stable. I've got a really nice offer from Jaeye in irc to maybe take a look over the OpenGL code. Sikk's stuff is impressive and really, I like it - but there is a certain hackish nature to most of it (I know, some irony here, I am very hacky ). I want things that are going to work correctly and not destroy performance. Not 'but people with fancy cards', we need to move the baseline up before we get bogged down

[nbohr1more]

Thanks for the info. Any chance that you'll borrow a few BFG improvements to the shadow code like "bounding shadow calcs to the light volume" and "gpu skinning volume changes rather then feeding massive amounts of skinned geometry every time a shadow moves"?

[Serpentine]

I guess, once again : I am only a bad generic programmer, graphics are something I really don't find interesting and as such I have no real understanding of code-wise, so if I can read and understand sections I'll try merge, but I wont be going out of my way to look for stuff, there's a massive list of better things to throw time at.

[nbohr1more]

Fair enough. (Just trying to see if your OpenGL friends already looked into this.)

Looking forward to the big Dhewg merge!