 |
broken_ambient_1.jpg (73,684 bytes) |
|
|
broken_ambient_2.jpg (132,494 bytes) |
|
|
Note: this has nothing to do with interactions, it is present even with r_skipInteractions. It happens both with simple and enhanced ambient rendering method. Settings like GLSL/FBO have no effect on the problem. I suspect it is a bad texture, since other objects do not have the issue. |
 |
I can't see the problem, neither on the screenshots or in game. Here's my screenshot. http://bugs.thedarkmod.com/file_download.php?file_id=497&type=bug I used r_singleLight and r_lightscale to have the ambient light only. |
|
|
|
|
|
When I try to see your screenshot, I see mantis error: APPLICATION ERROR 0001100 Issue 0 not found. SYSTEM WARNING: 'extract() expects parameter 1 to be array, boolean given' in '/usr/local/www/mantis-1.2.19_1/file_download.php' line 81 Do you mean you cannot notice the problem even on my screenshots? |
|
|
Try increasing gamma to make ambient colors bright enough. With low gamma this thing can be hard to notice. |
|
|
Yes. Try to refresh the webpage because I re-uploaded the picture. Otherwise here it is https://ibb.co/edzmDw |
|
|
As for Untitled.jpg which is the third attachment in this issue, you are too close to this rug to see the effect. Try to reproduce exactly the same camera position as on my screenshots. |
|
|
Umm... How did you turn the ceiling light off? |
|
|
Speaking on my first screenshot, it has two red marks like ">" and "<" signs inside red circle. Inspect closely the horizontal line between them. It splits the rug into two parts: the lower one is significantly brighter than the upper one. When you move slightly from that position, the splitting line moves up and down with you, which catches your eye quickly (unless you have low gamma, in which case you do not see ambient well anyway). |
|
|
I used water arrow to disable ceiling light =) |
|
|
Can see it now. I think it's simple depth-buffer fighting. Could it be some kind of polygon offset mapper's attempt that went wrong? Somebody fluent with DR should take a look. Or maybe it's just the scattered_dirt getting on top of the carpet because of insufficient depth buffer precision. Explains why r_skipAmbient 1 fixes it. |
 |
It turns out there are *two* func_static scattered_dirt02 patches, coplanar with each other and with the top of the floor brush. It doesn't look as though the mapper tried to offset anything (though scattered_dirt02 has DECAL_MACRO, implying sort decal and polygonOffset 1 on both patches). |
|
|
Ok, it looks like a map issue. This is very likely because most of the rugs around do not behave wrong. Sorry, false alarm then =) BTW, is it hard to check that if duplicate dirt is removed, the issue is gone? P.S. Should it be resolved as "won't fix" or changed to "mapping" category? |
|
|
I would vote for moving to the "mapping" category |
|
|
I'm not sure it is a map issue: the decal patches are below the rug. In fact they're as far below the rug as they could be. And using more than one blended decal (they use blend filter) is something a mapper might legitimately do. Edit: I just tried and failed to see any glitches on my 2.05 installation. If you want to test with one of the decal patches removed, setting "hide" "1" on func_static_199 should work non-destructively. |
|
|
PatentlyDangerous_BrightnessIssue.jpg (218,492 bytes) |
|
|
Added a screenshot from "Patently Dangerous" mission. The same (or almost the same) rug produces the same issue. You can see it very close to the mission start: just mantle over the fence and it will be there. |
|
|
Related to 0001201? |
|
|
Or this? http://forums.thedarkmod.com/topic/11825-decal-issue/ |
|
|
I have also noticed the same issue on one of the larger rugs in Saint Lucia. Have not taken a screenshot... |
|
|
>> the decal patches are below the rug. Yes they are, but the engine lifts all decals automatically (see cvars r_offsetXXX). Set the cvars to 0 and the carpet is OK but now the stain on the bar stand is broken. You can play with cvars and try to find values that work for this particular location. The radical solution would be to disable the hardware depth test and discard pixels in fragment shader which would bring some other glitches. We can also use a 32-bit depth precision in an FBO. |
|
|
I have linked a related issue, maybe interesting to read. It looks like the only proper way to fix it is to review all the offsets (depth and 3D) and create some plan which would get everything right. Adjusting offset for one particular scenario without checking all the other cases will most likely break some other cases =( When I set r_offsetFactor to -1 instead of -2, the issue starts happening at much smaller looking angle. With -0.6, I have to go very far to see the issue (Patently Dangerous is a great map to test it). According to my experience, such dependence on angle must not happen when polygonOffsetFactor is used (it is divided on the minimum looking angle over the polygon). Which leads me to conclusion that there is a plain 3D offset somewher (i.e. offset hardcoded in world coordinates). Perhaps if we remove this 3D offset, everything would work properly? |
 |
This old decal issue thats been around for a while now, have you guys got an idea on how to fix it..? |
|
|
In this particular case IMHO it would make sense to make the dirt decal to include the carpet as well. (Do they only walk with their dirty boots on the woodboard?) If we want to make an impression of carpet to cover the dirt then we need to somehow make the dirt part of the woodboard material. |
|
|
In the Inn Business case, the depth fight is between: func_static_199: consists of one quad patch with material "textures/darkmod/decals/dirt/scattered_dirt02" func_static_323: consists of one thin brush with upper side having material "textures/darkmod/carpet/runners/geometric01_red" The problem does happen in TDM 2.04 and later, and does not happen in TDM 2.03 and earlier. So this is caused by a careless fix during TDM 2.04 development. UPDATE: Broken by related issue 0004079. The values of r_offsetFactor/r_offsetUnits were changed from 0 / -600 to -2 / -0.1. Returning the old values back fixes the issue. I would say -600 and -0.1 are weird numbers here... Actually, the main difference is the addition of slope-based offset. |
|
|
The reason for changing offsets was originally reported here: https://forums.thedarkmod.com/index.php?/topic/16914-renderer-roadmap-for-204/&do=findComment&comment=364788 (basically, yet another depth fighting, but in different circumstances) The cvars are used to apply glPolygonOffset to materials which have one of: polygonOffset DECAL_MACRO / TWOSIDED_DECAL_MACRO In case of polygonOffset, there can be an additional value too, which serves as a factor on offset. But for some reason, it is applied to "units" only, not to "factor" (perhaps because "factor" was always zero): // set polygon offset if necessary if ( shader->TestMaterialFlag( MF_POLYGONOFFSET ) ) { qglEnable( GL_POLYGON_OFFSET_FILL ); qglPolygonOffset( r_offsetFactor.GetFloat(), r_offsetUnits.GetFloat() * shader->GetPolygonOffset() ); } |
|
|
And the reason why TDM switched from -0.1 / -1 to -2 / -0.1 is described here: https://forums.thedarkmod.com/index.php?/topic/16922-decals-drawing-over-stuff/&do=findComment&comment=385703 I guess that was not a good idea... |
|
|
I could never get qglPolygonOffset work reliably This better be fixed on the map level via e.g. vertex blending |
|
|
Nobody will redo existing maps, so any ideas like "let's do decals differently" can be ignored immediately. In this case, factor -2 is approximately equivalent to units -1500. Which confirms that factor is usually A LOT stronger than units. |
|
|
Basically, there are two conflicting goals: A) Making sure decal doesn't depth fight with the wall/floor it is on --- main property of decal B) If there is thin object on the wall/floor, it's desirable to avoiding decal being drawn on top of it --- the problem we have here Copying some more information copied from forum thread: https://forums.thedarkmod.com/index.php?/topic/20865-decals-and-depth-fighting/&do=findComment&comment=458784 1) Some decals are incorrectly placed by mappers. I.e. decal is not exactly on the wall, but a bit inside it, even when looking in DR. It works with larger offset, but it breaks when we try to reduce offset. One such example is in Inn Business FM at: 384.2 -510.42 69.09 -12.2 -32.4 0.0 2) Sometimes it is hard to put decal exactly onto the floor, because floor is a patch. One such minor example is in New Job FM at: 1252.02 -2161.64 -6.09 59.9 -27.4 0.0 Once again: it worked perfectly with larger offset, but when offset it reduced, it starts giving depth fighting, because decal is slightly inside floor. 3) Sometimes decal is precisely on the wall, but dmap changes geometry of the wall (so decal gets inside wall). This happens e.g. in Business As Usual FM at: -30.57 966.73 108.64 -25.3 46.3 0.0 Added reduced map to SVN as: test/business_extracted_decal.map Interestingly, this case does not work perfectly now, and becomes even worse if offset is reduced. This is the worst thing, since the geometry is routinely changed by 0.01-0.02. A very large polygon offset is needed to make decal look properly at close distance, and having same offset at large distance will be way too strong. So it seems that we need a different mechanism to cope with this problem, which will offset depth by 0.1 world units regardless of distance. The further analysis of case 3 showed that it comes from two sources: a) When dmap computes "windings" (polygons) of everything like brushes, it computes them with error of about 0.01 - 0.02 (see 0005580). b) Dmap often runs T-junction removal, which snaps all vertices to coordinates looking like "(integer+0.5)/32", which introduces error about 1/64 too (see 0005486). I will fix both problems in respective issues, but there are more potential sources of geometric shifts in dmap: c) If some vertices happen to be close to each other, they get merged together. d) Maybe something else I cannot remember now =) Aside from that, there are old maps (like Business As Usual), which most likely won't be recompiled. So the best bet right now is to do custom depth offset in fragment shader, which will correspond to fixed distance 0.1 in world space. |
|
|
Added map test/4634_polygonoffset.map to calibrate offsets. It has a series of thin brushes on floor, and a series of thin brushes on wall --- both covered by decal. Thicknesses are: 4.0, 2.0, 1.0, 0.75, 0.5, 0.25, 0.15 (the last ones are too thin indeed) Also there are various thin models on the floor. So everyone can test how much goals A and B fail. My testing showed that "factor 0.1" is roughly equal to "units 1" --- that's very crude, of course. So settings like "r_offsetfactor -0.3" & "r_offsetunits -3" make much more sense than the current ones. Perhaps we could switch to them for now --- not certain here. But the truth is that polygonoffset settings are too strong at large distances. At the same time, they are too weak at close distance, especially if decal and solid meshes don't match. I'd prefer offsetting depth manually in fragment shader by specified PHYSICAL distance. Attached a very dirty patch vs svn rev 9323. It adds cvar "r_offsetRawZ -0.1", which controls by how much doom units every fragment is pushed away from the eye (negative = push to the eye). However, this patch does not fully solve the problem 3 from Business As Usual (described in the previous post). If decal is inside wall by distance X, and we apply offset Y, then decal becomes invisible when we look under angle lower than asin(X/Y) (i.e. look almost tangentially). Perhaps we should compute viewing angle and divide offset by it (i.e. increase it), so that displacement along normal is always 0.1 --- not sure here. Anyway, applying depth shift in fragment shader causes technical problem. It is bad idea to apply it to all our shaders, because writing to depth is bad for performance. But it must be applied for decals both during depth prepass and during rendering, so depth program has to be compiled into two instances: one or normal rendering (no depth write), one for decals (depth write). 4634_temp_offsetrawz.patch (8,074 bytes) |
|
|
So are we going to stop using the polygon offset for good now? I was never able to produce decent output, but I always assumed I was simply too stupid to get it right. Quite frustrating actually - how hard is it for the driver to increment the depth int value by 1!? As for shaders, can't we do it in vertex shader by moving the transformed vertex 0.1 units closer to viewer origin? |
|
|
"r_offsetunits -1" does decrement depth by 1, but it does not stop depth-fighting. There are many numeric inaccuracies which are hard to bound reliably. My current plan is to combine shift by 0.1 along normal with "offsetunits -1". I'm afraid polygonoffset is still needed for large distances. No, it is not possible to offset eye Z by 0.1 via changing vertex coordinates. The same applies to offsetting depth, I suppose. With perspective projection matrix things are transformed in nonlinear way. Just imagine that you stand near a long way and look along it: two vertices far ahead, two vertices far behind =) |
|
|
>> "r_offsetunits -1" does decrement depth by 1, but it does not stop depth-fighting. But it should, in theory - that's what I call frustrating. >> Just imagine that you stand near a long way and look along it: two vertices far ahead, two vertices far behind =) Well, it could be subtract 0.1 and multiply by 0.99999 |
- Anonymous
