 |
I believe duzenko changed the mirrorRenderMap behaviour while working on 0004615: https://bugs.thedarkmod.com/view.php?id=4615#c9329 https://bugs.thedarkmod.com/view.php?id=4615#c9335 |
 |
This really needs to be better documented for the end users. People use both TDM and Mod wikis, assuming there's a an overlap in stuff like decl syntax and parameters. Cases like that mean hours of research and frustration. |
 |
But it would be great to restore it as performance optimization, especially for water reflections. As an example, the upcoming "Displacement" mission has rather low performance at "845.31 1192.44 151.73 80.9 -89.2 0.0". When the player looks directly at the reflecting water. |
|
|
The implementation is here. Some generic stuff (no behavior changes): r11054 Added stack of subviews to natvis of viewDef_t. r11055 Renamed viewDef_t: isMirror -> isMirrorInverted. r11056 Added flag isMirrorGen to viewDef_t. And some new parameters for mirrors and remotes: r11057 Supported mirrorResolutionFactor material flag to make low-resolution mirrored surface. r11058 Supported "remoteResolution" setting for remote subview materials. r11059 Changed the order of arguments in remoteResolution, made 3D resolution optional. If we want to have reflective surface with 1/3 lower resolution, then we can write it like this: mirrorRenderMap mirrorResolutionFactor 0.333 map _dynamic The first line enables the mirror subview. The second line sets resolution factor (values > 1 are pointless), here it's 1/3. The last line is supposed to specify texture name, but right now it can be anything with dynamic flag, the most generic such internal image is "_dynamic". If there are some more nested mirrors, they'll all have resolution 1/3 or lower. For instance, if we have 3 nested mirrors with factors: 1/3 * 1/2 * 1/4, then the effective factor would be 1/4 (minimum). Speaking of remote cameras, the old way of setting resolution is deprecated: remoteRenderMap 232 232 It should still work more or less like in 2.13 and earlier though, but these 232 is not the real resolution, and the effective resolution in this case depends on player's screen resolution... The new recommended way is this: remoteRenderMap remoteResolution 512 512 map _dynamic Here the first line enables the remote subview, and the second one sets the rendering resolution of the screen. And alternative way looks like this: remoteRenderMap remoteResolution 1024 1024 10.0 map _dynamic Note the third optional argument of remoteResolution: it sets resolution in "pixels per doom units". If you control the resolution this way, then making the screen 2x larger will automatically make the resolution 2x times higher. The real effective resolution in this case is min(10 * worldSize, 1024) |
|
|
Added two GPU optimizations for subviews: r11061 Use scissor to copy only portion of screen occupied by the mirror into mirror texture. r11065 Added an optimization to reduce effective texture size for a remote screen if it looks small on player screen. Both of them should help with GPU-side work (especially bandwidth) when mirror/remote takes little space on player screen. Unfortunately, the CPU-side work is still the same, running frontend for subview can still be costly. The kill switches for the optimizations are: r_copyRenderUseScissor r_remoteLimitResolutionByScreenSize |
- Anonymous
