 |
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. |
|
|
New TheDarkMod.exe committed at rev 14032 |
|
|
This needs one more tweak: the environmental variables that hold _currentRender dimensions need to be set for _currentDepth too. |
 |
Maybe make this a child of 0003684 ? |
|
|
I hadn't spotted that excellent list. I'll hook up the duplicate issues I've created. |
|
|
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). |
|
|
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 |
|
|
Committed the new constant at rev 6131 (code) rev 14036 (binary) |
|
|
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. |
|
|
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. |
|
|
At rev 6132 |
|
|
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. |
|
|
Not worth a separate commit: I'll add it in my next commit for 3878 (soft particles). |
|
|
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. |
- Anonymous
