View Issue Details

IDProjectCategoryView StatusLast Update
0003877The Dark ModFeature proposalpublic24.12.2014 12:51
ReporterSteveL Assigned ToSteveL  
PrioritynormalSeveritynormalReproducibilityN/A
Status resolvedResolutionfixed 
Product VersionTDM 2.02 
Target VersionTDM 2.03Fixed in VersionTDM 2.03 
Summary0003877: Allow shaders to access scene depth (co-author: revelator)
DescriptionidTech4 performs an early depth pass, to establish the depth of the scene before anything is drawn, so there's no overdraw of solid materials. Reference this via a new global image _currentDepth to allow shaders to make use of it for sfx without needing post-processing or extra render passes.
Additional InformationDetails of solution starting here: http://forums.thedarkmod.com/topic/15178-tdm-engine-development-page/page__view__findpost__p__355880
TagsNo tags attached.

Relationships

related to 0003878 resolvedSteveL Soft particles 
related to 0003879 resolvedSteveL Warping post processes (water and glass) distort foreground objects 
related to 0003883 closedSteveL Post processing shaders doing more sums than needed 
child of 0003684 new Investigate GPL Renderer Improvements 

Activities

SteveL

SteveL

17.10.2014 20:26

developer   ~0007074

Committed at revision 6127

renderer\draw_common.cpp
renderer\Image.h
renderer\Image_init.cpp
renderer\Image_load.cpp
renderer\Material.cpp
renderer\RenderSystem_init.cpp
renderer\tr_local.h

Includes:
+ New _currentDepth global image accessible by any shader. Unlike _currentRender, using this keyword in a material file does not delay the shader being drawn.
+ New ignoreDepth material file keyword. Prevents the shader being clipped by solid geometry.
+ New cVar r_skipDepthCapture. For testing, so if anyone experiences a change in fps we can diagnose it. None experienced on my system.
SteveL

SteveL

17.10.2014 20:30

developer   ~0007075

New TheDarkMod.exe committed at rev 14032
SteveL

SteveL

18.10.2014 07:48

developer   ~0007076

This needs one more tweak: the environmental variables that hold _currentRender dimensions need to be set for _currentDepth too.
nbohr1more

nbohr1more

19.10.2014 20:50

developer   ~0007078

Maybe make this a child of 0003684 ?
SteveL

SteveL

22.10.2014 18:57

developer   ~0007083

I hadn't spotted that excellent list. I'll hook up the duplicate issues I've created.
SteveL

SteveL

22.10.2014 19:08

developer   ~0007084

On the environmental variables: shaders that use _currentRender do unnecessary work. The _currentRender capture in the renderer c++ code sets environmental constants for both the screen size and the power-of-two texture size, to allow shaders to translate a screen position to a texture coordinate. But when you lay out the math, only the reciprocal of the power-of-two texture size is really needed to do that. The screen size cancels out in the algebra. That's how I did it in the "depth window" shader and video I posted in the engine thread. I'll add a new environmental constant for depth-capture-related fragment programs which holds that reciprocal, and maybe open another tracker to change the shaders using _currentRender if it turns out that they're doing that extra calculation for every pixel instead of just once (I don't have the code in front of me right now).
SteveL

SteveL

24.10.2014 17:10

developer   ~0007089

Last edited: 24.10.2014 20:26

View 5 revisions

Notes on environmental constants

- Vertex programs and fragment programs have independent numbered slots for these constants. Fragment programs only use 0..3
- It seems different values are stored in 0..1 for different draw calls. They are "constant" for one draw. Interactions put colors in there. PP effects put _currentRender size in there. The meanings are not defined anywhere, presumably because of the reuse... they're just contextless index numbers that have to be matched correctly in shaders that use them.
- Depth will be used during interactions as well as PP effects, so we'll use a new numbered slot: 4

SteveL

SteveL

24.10.2014 19:37

developer   ~0007090

Committed the new constant at rev 6131 (code) rev 14036 (binary)
SteveL

SteveL

26.10.2014 12:07

developer   ~0007092

Last edited: 26.10.2014 12:42

View 2 revisions

Another tweak required. The attempt to share constants with currentRender goes wrong if the map doesn't use ANY post-process effects at all, because currentRender's size then sits at 16x16 for the whole map and it gets passed into the environmental variables whether it's in use or not. Which means depth gets sampled wrongly if there's no glass or water etc in the map.

Best split them up permanently anyway. The code doesn't guarantee that _currentRender will be the same size as _currentDepth, and a new constant is free.

SteveL

SteveL

26.10.2014 12:31

developer   ~0007093

I've added comments to RB_SetProgramEnvironment to explain how these parameters are used in the renderer. They get re-used with entirely different meanings while light interactions are being drawn, so writing it down will help avoid future confusion.
SteveL

SteveL

26.10.2014 13:15

developer   ~0007094

At rev 6132
SteveL

SteveL

31.10.2014 18:57

developer   ~0007102

Added a small fix for ancient graphics cards that might downsize the depth texture due to hardware limits, in case there's anyone out there using an elderly gfx card with a big screen! The screen-to-texture mapping ratio now gets set using the screen size rounded up to the next power of two, instead of the actual depth image size. NB this is zero change for modern cards, as that'll be its size already.
SteveL

SteveL

31.10.2014 18:59

developer   ~0007103

Not worth a separate commit: I'll add it in my next commit for 3878 (soft particles).
SteveL

SteveL

24.12.2014 01:08

developer   ~0007273

Last edited: 24.12.2014 01:09

View 2 revisions

I've added 2 more constants to the program.env[4] setting passed by the engine to fragment shaders, to handle situations where the _currentDepth image is a different size from _currentRender. From the code in draw_common.cpp:

// 0003877: Allow shaders to access depth buffer.
// Two useful ratios are packed into this parm: [0] and [1] hold the x,y multipliers you need to map a screen
// coordinate (fragment position) to the depth image: those are simply the reciprocal of the depth
// image size, which has been rounded up to a power of two. Slots [3] and [4] hold the ratio of the depth image
// size to the current render image size. These sizes can differ if the game crops the render viewport temporarily
// during post-processing effects. The depth render is smaller during the effect too, but the depth image doesn't
// need to be downsized, whereas the current render image does get downsized when it's captured by the game after
// the skybox render pass. The ratio is needed to map between the two render images.
parm[0] = 1.0f / globalImages->currentDepthImage->uploadWidth;
parm[1] = 1.0f / globalImages->currentDepthImage->uploadHeight;
parm[2] = static_cast<float>(globalImages->currentRenderImage->uploadWidth) / globalImages->currentDepthImage->uploadWidth;
parm[3] = static_cast<float>(globalImages->currentRenderImage->uploadHeight) / globalImages->currentDepthImage->uploadHeight;
qglProgramEnvParameter4fvARB( GL_FRAGMENT_PROGRAM_ARB, 4, parm );

Also updated HeatHazeWithMaskAndDepth.vfp to use this ratio, as it needs to find the depth of various pixels from currentRender.

Issue History

Date Modified Username Field Change
16.10.2014 22:40 SteveL New Issue
16.10.2014 22:40 SteveL Status new => assigned
16.10.2014 22:40 SteveL Assigned To => SteveL
16.10.2014 23:03 SteveL Relationship added related to 0003878
16.10.2014 23:11 SteveL Relationship added related to 0003879
16.10.2014 23:59 SteveL Summary Allow shaders to access scene depth => Allow shaders to access scene depth (co-author: revelator)
16.10.2014 23:59 SteveL Additional Information Updated View Revisions
17.10.2014 20:26 SteveL Note Added: 0007074
17.10.2014 20:26 SteveL Status assigned => resolved
17.10.2014 20:26 SteveL Fixed in Version => TDM 2.03
17.10.2014 20:26 SteveL Resolution open => fixed
17.10.2014 20:30 SteveL Note Added: 0007075
18.10.2014 07:48 SteveL Note Added: 0007076
18.10.2014 07:48 SteveL Status resolved => assigned
19.10.2014 20:50 nbohr1more Note Added: 0007078
22.10.2014 18:51 SteveL Relationship added child of 0003684
22.10.2014 18:57 SteveL Note Added: 0007083
22.10.2014 19:08 SteveL Note Added: 0007084
24.10.2014 17:10 SteveL Note Added: 0007089
24.10.2014 17:11 SteveL Note Edited: 0007089 View Revisions
24.10.2014 17:12 SteveL Note Edited: 0007089 View Revisions
24.10.2014 17:23 SteveL Note Edited: 0007089 View Revisions
24.10.2014 17:51 SteveL Relationship added related to 0003883
24.10.2014 19:37 SteveL Note Added: 0007090
24.10.2014 19:42 SteveL Status assigned => resolved
24.10.2014 20:26 SteveL Note Edited: 0007089 View Revisions
26.10.2014 12:07 SteveL Note Added: 0007092
26.10.2014 12:08 SteveL Status resolved => assigned
26.10.2014 12:31 SteveL Note Added: 0007093
26.10.2014 12:42 SteveL Note Edited: 0007092 View Revisions
26.10.2014 13:15 SteveL Status assigned => resolved
26.10.2014 13:15 SteveL Note Added: 0007094
31.10.2014 18:57 SteveL Note Added: 0007102
31.10.2014 18:59 SteveL Note Added: 0007103
23.12.2014 17:53 SteveL Status resolved => assigned
24.12.2014 01:08 SteveL Note Added: 0007273
24.12.2014 01:09 SteveL Note Edited: 0007273 View Revisions
24.12.2014 12:51 SteveL Status assigned => resolved