 |
Thread: http://forums.thedarkmod.com/topic/16528-mappers-tools-for-commands-for-performance-troubleshooting/ Grayman: "It requires textures/common/overdraw.tga, and that's missing. I don't see it in Doom3 either. Edit: The code looks like it doesn't care if the image is missing, though, as long as the material (textures/common/overdrawtest) exists, and it does. It's done in the renderer, which I'm not familiar with. " |
|
|
Testing: So... there definitely seems to be some kinda functionality in r_showOverDraw... I set the material to map _white and it painted 90% of the screen white save a small rectangle. I then tried the blend filter with map _fog and it rendered stars from the skybox I was flying blind but I was able to invisibly toggle the console and invoke r_showOverDraw 0 to get back to the normal render. |
 |
I've not read the code yet but I assume this should work as follows: every surface gets drawn as a 10% (or some small number) additive blend using a plain texture. So the brighter a surface is, the more overdraw on that spot of the screen. Hmmm, should it ignore transparencies? I'll have a look what the renderer is trying to do with it when I finish a couple of other issues. |
|
|
This command is currently implemented as a Horrible Hack that looks like it could never have worked. Right after setting up all the surfaces to be drawn in the current frame, RB_DrawView() calls RB_ShowOverdraw() which tests the value of the cvar and then hacks the list of surfaces to be drawn (using const_cast to modify what should be read-only memory) to replace the materials on all surfaces with "textures/common/overdrawtest". It also clears all lights and moves the surfaces hit by lights to the unlit surface list. So if a surface is hit by 3 lights, it'll get drawn 3 times even though the lights are no longer doing anything while the cvar is active. "textures/common/overdrawtest" must have been a % additive blend material, e.g. _white with rgb 0.1 I don't think it can ever have worked. There's a point where it allocates memory for the new list of draw surfs and it allocates the wrong amount due to missing brackets. So if a mapper did try to provide a "textures/common/overdrawtest" then the game would likely hard crash immediately. The functionality is limited even if we fix it. It's not set up to handle anything that generates new draw surfs in the back end: fogs, for example. Fog lights and blend lights do cause surfaces to be drawn again (=more overdraw) but those extra surfaces are not known about at the point where RB_ShowOverdraw is doing its evil, so they will not be included. And I'm not sure that's the kind of overdraw that people would be looking for. Materials with multiple diffuse stages cause more draws on the same surface -- should they be counted as overdraw too? Is this feature useful and how should it work? It could probably be implemented better using cvar r_materialOverride with a % material as defined above, but that still wouldn't cater for fogs and blends. Those could be fixed easily enough. But the message it gives would always be confusing. Whether a surface is overdrawn or not is not a yes/no question. Surfaces that are hidden by other surfaces send themselves to the GPU to be drawn, but the GPU will cull them before it does expensive light shading operations. Are those "drawn" or not? We can discuss fixing it when we know what questions people want it to answer. Maybe best to take this back to the forum for discussion. |
|
|
Use case scenario: Typically, you want to get a rough idea of how many obscured tris are being rendered because transparent surfaces are forcing them to render due to the limitations of occlusion culling for transparency. This way you can decide to cut-back on transparent surfaces, move hidden tris further from the vis projection, or add func_portals (etc) to force hidden overdraw tris to disappear. |
|
|
Doesn't r_showtris give you that same info and with better precision because you can specify 1/2/3? 1 gives you all tris that go through the full shading process and get coloured-in, 2 shows you all tris that are facing you, and 3 shows you all tris that are sent to the gpu. I guess a color-based version might be easier on the eye. r_showtris is hopelessly confusing in complicated spots. |
|
|
Yeah, something that better signifies where transparent surfaces are the cause of the problem would help. Side note: Hmm r_showLightCount 3 is another overdraw inspector. I wonder if it differs from the technique hinted at here other than it's focus on light based draw? |
|
|
Not worth the effort. If \ whenever Quake 4 source is ever released we can use the solution there to fix this. |
- Anonymous
