 |
Stuck at a road block - can't see where the skybox texture is used. But it's not a glproc. |
 |
Hmm // skybox surfaces need a dynamic texgen switch( shader->Texgen() ) { case TG_SKYBOX_CUBE: R_SkyboxTexGen( drawSurf, tr.viewDef->renderView.vieworg ); return; case TG_WOBBLESKY_CUBE: R_WobbleskyTexGen( drawSurf, tr.viewDef->renderView.vieworg ); return; } in R_AddDrawSurf in tr_light.cpp |
|
|
Put a breakpoint on each of these two - none were hit in Thief's Den or Rift |
|
|
Chalice of Kings, however, did hit R_WobbleskyTexGen. It also does not lose the sky after r_skipcopytexture 1. |
|
|
What about here: if ( drawSurfs[0]->material->GetSort() >= SS_POST_PROCESS ) { if ( r_skipPostProcess.GetBool() ) { return 0; } // 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, true ); } backEnd.currentRenderCopied = true; } in draw_common.cpp > RB_STD_DrawShaderPasses What you might be looking into is the sort order. The problem being that we don't want the skybox to write over other surfaces. |
|
|
I think this code is responsible for blur, eye-blood, etc. ... tdm_portal_sky.mtr has this: map _currentRender This is how it probably links skybox as texture but I still don't know where it texgen's it (except for rarely used wobblesky) ... At this point I don't see how the skybox can be drawn last since surfaces like water, eye-blood, smoke, etc would be overwritten. Unless there is a way to draw it right after opaque surfaces??? Still the question remains if copy-to-texture can be avoided. ... The idea here is to somehow make the skybox surfaces completely invisible. That way it will just show the skybox pixels left from the previous stage. ... The texgen could be TG_SCREEN |
|
|
Since it doesn't seem to be possible to avoid the copy operation without some serious structural changes, I went back to look into _currentRender itself. At the end of the chain in image_load.cpp is CopyFramebuffer. This is where the actual GL calls to copy the framebuffer for _currentRender images are provoked. Maybe see if the legacy GL calls there can be updated with modern FrameBuffer based commands? |
|
|
No, actually I think copy can be avoided. If the "ceiling" is not drawn at all then the skybox pixels could be already there from the previous stage. ... Right now I am looking at how to identify "ceiling" geometry to skip in back renderer. ... Could it be surf->material->GetName() = "textures/smf/portal_sky" ??? |
|
|
Looks like a good lead: RenderWorld_load.cpp idRenderWorldLocal::AddWorldModelEntities // add the world model for each portal area // we can't just call AddEntityDef, because that would place the references // based on the bounding box, rather than explicitly into the correct area |
|
|
That worked but the pixels aren't there. Does it glClear somewhere? ... What if don't do qglClear( GL_COLOR_BUFFER_BIT ) at all? Sounds like a weird but valid optimization. ... Pixels still not there even after r_clear 0. However world pixels are not cleared. ... There appears to be a mysterious black plane above the ceiling. |
|
|
Dumping framebuffer step-by-step shows that the black thing happens in RB_STD_FillDepthBuffer ... In RB_RenderDrawSurfListWithFunction ... RB_T_FillDepthBuffer writes to color buffer ??? |
|
|
Changed the renderer to skip the skybox surfaces in both depth pass and shader pass. Texture copy skipped as well. This behaviour is controlled by the g_enablePortalSky cvar. |
|
|
Moved the filtering code from back to front renderer to save a few more CPU cycles. Added skybox debug tool. |
- Anonymous
