View Issue Details

IDProjectCategoryView StatusLast Update
0004414The Dark ModTweakingpublic24.10.2020 03:27
Reporterduzenko Assigned Toduzenko  
PrioritynormalSeveritytrivialReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.05Fixed in VersionTDM 2.05 
Summary0004414: See if skybox can be rendered faster
DescriptionCurrently TDM
1 - draws skybox filling entire framebuffer
2 - copies framebuffer to a texture sized power of two
3 - uses the skybox texture to render geometry (?)
It could save few millisecond/milliwatts if we drew skybox in the end, skipping the copy-to-texture step and utilizing Z-test to skip invisible pixels.
TagsNo tags attached.

Relationships

related to 0004182 resolvedSteveL Glass crack decals are not visible against skybox backdrop 
related to 0004417 closedduzenko See if surfaces need to write to color buffer at the depth stage 
parent of 0005365 closedduzenko Portal Sky has been partially broken since 2.05 
related to 0003684 new Investigate GPL Renderer Improvements 
related to 0004635 closedstgatilov New portalSky method is see-through like caulk skies... which isn't always desirable 

Activities

duzenko

duzenko

07.11.2016 18:39

developer   ~0008450

Stuck at a road block - can't see where the skybox texture is used.
But it's not a glproc.
nbohr1more

nbohr1more

07.11.2016 19:48

developer   ~0008452

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
duzenko

duzenko

07.11.2016 20:32

developer   ~0008454

Last edited: 13.11.2016 15:57

Put a breakpoint on each of these two - none were hit in Thief's Den or Rift

duzenko

duzenko

07.11.2016 20:36

developer   ~0008455

Last edited: 07.11.2016 20:45

Chalice of Kings, however, did hit R_WobbleskyTexGen.
It also does not lose the sky after r_skipcopytexture 1.

nbohr1more

nbohr1more

07.11.2016 22:16

developer   ~0008456

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.
duzenko

duzenko

13.11.2016 15:54

developer   ~0008474

Last edited: 13.11.2016 18:46

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

nbohr1more

nbohr1more

13.11.2016 18:49

developer   ~0008476

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?
duzenko

duzenko

13.11.2016 18:51

developer   ~0008477

Last edited: 13.11.2016 18:57

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" ???

nbohr1more

nbohr1more

13.11.2016 19:00

developer   ~0008478

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
duzenko

duzenko

13.11.2016 19:01

developer   ~0008479

Last edited: 13.11.2016 19:45

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.

duzenko

duzenko

14.11.2016 18:42

developer   ~0008481

Last edited: 14.11.2016 19:08

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

duzenko

duzenko

14.11.2016 19:50

developer   ~0008482

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.
duzenko

duzenko

16.11.2016 13:09

developer   ~0008489

Moved the filtering code from back to front renderer to save a few more CPU cycles.
Added skybox debug tool.

Issue History

Date Modified Username Field Change
07.11.2016 18:38 duzenko New Issue
07.11.2016 18:38 duzenko Status new => assigned
07.11.2016 18:38 duzenko Assigned To => duzenko
07.11.2016 18:39 duzenko Note Added: 0008450
07.11.2016 19:48 nbohr1more Note Added: 0008452
07.11.2016 20:32 duzenko Note Added: 0008454
07.11.2016 20:36 duzenko Note Added: 0008455
07.11.2016 20:45 duzenko Note Edited: 0008455
07.11.2016 22:16 nbohr1more Note Added: 0008456
13.11.2016 15:54 duzenko Note Added: 0008474
13.11.2016 15:57 duzenko Note Edited: 0008454
13.11.2016 16:12 duzenko Note Edited: 0008474
13.11.2016 16:12 duzenko Relationship added related to 0004182
13.11.2016 17:08 duzenko Note Edited: 0008474
13.11.2016 17:11 duzenko Note Edited: 0008474
13.11.2016 18:46 duzenko Note Edited: 0008474
13.11.2016 18:49 nbohr1more Note Added: 0008476
13.11.2016 18:51 duzenko Note Added: 0008477
13.11.2016 18:53 duzenko Note Edited: 0008477
13.11.2016 18:57 duzenko Note Edited: 0008477
13.11.2016 19:00 nbohr1more Note Added: 0008478
13.11.2016 19:01 duzenko Note Added: 0008479
13.11.2016 19:02 duzenko Note Edited: 0008479
13.11.2016 19:05 duzenko Note Edited: 0008479
13.11.2016 19:09 duzenko Note Edited: 0008479
13.11.2016 19:12 duzenko Note Edited: 0008479
13.11.2016 19:45 duzenko Note Edited: 0008479
14.11.2016 18:42 duzenko Note Added: 0008481
14.11.2016 18:48 duzenko Note Edited: 0008481
14.11.2016 19:08 duzenko Note Edited: 0008481
14.11.2016 19:50 duzenko Note Added: 0008482
14.11.2016 22:05 nbohr1more Status assigned => feedback
14.11.2016 22:05 nbohr1more Product Version => SVN
14.11.2016 22:05 nbohr1more Target Version => TDM 2.05
16.11.2016 13:09 duzenko Note Added: 0008489
16.11.2016 13:09 duzenko Status feedback => assigned
22.11.2016 17:41 nbohr1more Status assigned => resolved
22.11.2016 17:41 nbohr1more Resolution open => fixed
22.11.2016 17:41 nbohr1more Fixed in Version => TDM 2.05
22.11.2016 19:51 nbohr1more Relationship added related to 0004417
01.12.2016 21:07 nbohr1more Relationship added related to 0003684
15.10.2017 17:22 VanishedOne Relationship added related to 0004635
24.10.2020 03:27 nbohr1more Relationship added parent of 0005365