View Issue Details

IDProjectCategoryView StatusLast Update
0004634The Dark ModGraphicspublic29.04.2021 15:50
Reporterstgatilov Assigned Tostgatilov  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product VersionTDM 2.04 
Target VersionTDM 2.10 
Summary0004634: Decal depth fighting (Inn Business: "rug in tavern is not smooth")
DescriptionThe rug look bad: its color (brightness) changes hardly from light to dark at a screen-horizontal line.
See screenshot.
Steps To Reproduce1. Start Inn Business map.
2. Run "notarget" command in console.
3. Enter the tavern through the main entrance.
4. Go to the place behind the bar/table.

At some moment you'll notice that the rug (behind the bar) is hardly split by a horizontal line into two parts with different brightness.
See screenshot.
TagsNo tags attached.

Relationships

related to 0004079 resolvedSteveL Decals drawing over stuff in front 
related to 0005580 resolvedstgatilov Dmap : better windings precision 

Activities

stgatilov

stgatilov

14.10.2017 07:48

administrator  

broken_ambient_1.jpg (73,684 bytes)   
broken_ambient_1.jpg (73,684 bytes)   
stgatilov

stgatilov

14.10.2017 07:48

administrator  

broken_ambient_2.jpg (132,494 bytes)   
broken_ambient_2.jpg (132,494 bytes)   
stgatilov

stgatilov

14.10.2017 07:50

administrator   ~0009466

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.
duzenko

duzenko

14.10.2017 12:13

developer   ~0009468

Last edited: 14.10.2017 12:14

View 2 revisions

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.

duzenko

duzenko

14.10.2017 12:16

developer  

Untitled.jpg (274,510 bytes)
stgatilov

stgatilov

14.10.2017 12:32

administrator   ~0009469

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?
stgatilov

stgatilov

14.10.2017 12:33

administrator   ~0009470

Try increasing gamma to make ambient colors bright enough. With low gamma this thing can be hard to notice.
duzenko

duzenko

14.10.2017 12:34

developer   ~0009471

Last edited: 14.10.2017 12:36

View 3 revisions

Yes.
Try to refresh the webpage because I re-uploaded the picture.
Otherwise here it is https://ibb.co/edzmDw

stgatilov

stgatilov

14.10.2017 12:35

administrator   ~0009472

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.
duzenko

duzenko

14.10.2017 12:36

developer   ~0009473

Umm...
How did you turn the ceiling light off?
stgatilov

stgatilov

14.10.2017 12:39

administrator   ~0009474

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).
stgatilov

stgatilov

14.10.2017 12:40

administrator   ~0009475

I used water arrow to disable ceiling light =)
duzenko

duzenko

15.10.2017 10:16

developer   ~0009480

Last edited: 15.10.2017 10:40

View 5 revisions

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.

VanishedOne

VanishedOne

15.10.2017 15:23

reporter   ~0009481

Last edited: 15.10.2017 15:25

View 2 revisions

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).

stgatilov

stgatilov

15.10.2017 16:27

administrator   ~0009482

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?
duzenko

duzenko

15.10.2017 16:40

developer   ~0009483

I would vote for moving to the "mapping" category
VanishedOne

VanishedOne

15.10.2017 17:30

reporter   ~0009484

Last edited: 15.10.2017 17:43

View 2 revisions

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.

stgatilov

stgatilov

11.11.2017 15:35

administrator  

stgatilov

stgatilov

11.11.2017 15:37

administrator   ~0009569

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.
duzenko

duzenko

11.11.2017 18:52

developer   ~0009578

Related to 0001201?
VanishedOne

VanishedOne

12.11.2017 21:46

reporter   ~0009587

Or this? http://forums.thedarkmod.com/topic/11825-decal-issue/
stgatilov

stgatilov

14.11.2017 16:59

administrator   ~0009614

I have also noticed the same issue on one of the larger rugs in Saint Lucia. Have not taken a screenshot...
duzenko

duzenko

14.11.2017 19:43

developer   ~0009619

Last edited: 14.11.2017 19:48

View 4 revisions

>> 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.

stgatilov

stgatilov

31.12.2017 07:41

administrator   ~0009947

Last edited: 31.12.2017 07:42

View 2 revisions

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?

user81

28.03.2018 08:37

  ~0010173

This old decal issue thats been around for a while now, have you guys got an idea on how to fix it..?
duzenko

duzenko

28.03.2018 09:31

developer   ~0010196

Last edited: 28.03.2018 09:32

View 2 revisions

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.

stgatilov

stgatilov

28.03.2021 05:06

administrator   ~0013812

Last edited: 28.03.2021 05:16

View 2 revisions

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.
stgatilov

stgatilov

28.03.2021 05:21

administrator   ~0013813

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() );
  }
stgatilov

stgatilov

28.03.2021 06:48

administrator   ~0013814

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...
duzenko

duzenko

28.03.2021 09:37

developer   ~0013815

I could never get qglPolygonOffset work reliably
This better be fixed on the map level via e.g. vertex blending
stgatilov

stgatilov

28.03.2021 11:41

administrator   ~0013816

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.
stgatilov

stgatilov

09.04.2021 17:44

administrator   ~0013830

Last edited: 10.04.2021 04:11

View 4 revisions

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.
stgatilov

stgatilov

28.04.2021 17:02

administrator   ~0013931

Last edited: 28.04.2021 17:02

View 2 revisions

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)   
Index: glprogs/oldStage.fs
===================================================================
--- glprogs/oldStage.fs	(revision 9322)
+++ glprogs/oldStage.fs	(working copy)
@@ -2,6 +2,7 @@
 
 uniform float u_screenTex;
 uniform sampler2D u_tex0;
+uniform float u_offsetRawZ;
 
 in vec4 var_TexCoord0;
 in vec4 var_Color;
@@ -8,6 +9,21 @@
 
 out vec4 FragColor;
 
+#pragma tdm_include "tdm_transform.glsl"
+float depthToZ(float depth) {
+	float clipZ = 2.0 * depth - 1.0;
+	float A = u_projectionMatrix[2].z;
+	float B = u_projectionMatrix[3].z;
+	return B / (A + clipZ);
+}
+float zToDepth(float z) {
+	float A = u_projectionMatrix[2].z;
+	float B = u_projectionMatrix[3].z;
+	float clipZ = (B / z) - A;
+    return (clipZ + 1.0) * 0.5;
+}
+
+
 void main() {
 	vec4 tex;
 	if (u_screenTex == 1.0) {
@@ -18,4 +34,12 @@
 	} else
 		tex = textureProj(u_tex0, var_TexCoord0);
 	FragColor = tex*var_Color;
+
+    if (u_offsetRawZ != 0.0) {
+        float newDepth = zToDepth(depthToZ(gl_FragCoord.z) + u_offsetRawZ);
+        newDepth = min(newDepth, gl_FragCoord.z);
+        gl_FragDepth = newDepth;
+    }
+    else
+        gl_FragDepth = gl_FragCoord.z;
 }
\ No newline at end of file
Index: glprogs/stages/depth/depth.frag.glsl
===================================================================
--- glprogs/stages/depth/depth.frag.glsl	(revision 9322)
+++ glprogs/stages/depth/depth.frag.glsl	(working copy)
@@ -25,6 +25,23 @@
 }
 #endif
 
+uniform ViewParamsBlock {
+	uniform mat4 u_projectionMatrix;
+};
+float depthToZ(float depth) {
+	float clipZ = 2.0 * depth - 1.0;
+	float A = u_projectionMatrix[2].z;
+	float B = u_projectionMatrix[3].z;
+	return B / (A + clipZ);
+}
+float zToDepth(float z) {
+	float A = u_projectionMatrix[2].z;
+	float B = u_projectionMatrix[3].z;
+	float clipZ = (B / z) - A;
+    return (clipZ + 1.0) * 0.5;
+}
+
+
 void main() {
 	if (clipPlaneDist < 0.0)
 		discard;
@@ -33,6 +50,14 @@
 	if (gl_FragCoord.x < scissor.x || gl_FragCoord.y < scissor.y || gl_FragCoord.x >= scissor.x + scissor.z || gl_FragCoord.y >= scissor.y + scissor.w)
 		discard;
 	
+    if (params[var_DrawId].offsetRawZ != 0.0) {
+        float newDepth = zToDepth(depthToZ(gl_FragCoord.z) + params[var_DrawId].offsetRawZ);
+        newDepth = min(newDepth, gl_FragCoord.z);
+        gl_FragDepth = newDepth;
+    }
+    else
+        gl_FragDepth = gl_FragCoord.z;
+
 	if (params[var_DrawId].alphaTest < 0) {
 		FragColor = params[var_DrawId].color;
 	}
Index: glprogs/stages/depth/depth.params.glsl
===================================================================
--- glprogs/stages/depth/depth.params.glsl	(revision 9322)
+++ glprogs/stages/depth/depth.params.glsl	(working copy)
@@ -7,7 +7,7 @@
 	uvec4 scissor;
 	uvec2 texture;
 	float alphaTest;
-	float padding;
+	float offsetRawZ;
 };
 
 layout (std140) uniform PerDrawCallParamsBlock {
Index: glprogs/stages/interaction/interaction.ambient.fs.glsl
===================================================================
--- glprogs/stages/interaction/interaction.ambient.fs.glsl	(revision 9322)
+++ glprogs/stages/interaction/interaction.ambient.fs.glsl	(working copy)
@@ -136,4 +136,5 @@
 	}
 
 	FragColor = light;
+    gl_FragDepth = gl_FragCoord.z;
 }
Index: glprogs/stages/interaction/interaction.stencil.fs.glsl
===================================================================
--- glprogs/stages/interaction/interaction.stencil.fs.glsl	(revision 9322)
+++ glprogs/stages/interaction/interaction.stencil.fs.glsl	(working copy)
@@ -106,4 +106,5 @@
 	if (u_shadows && u_softShadowsQuality > 0)
 		StencilSoftShadow();
 	FragColor.a = 1.0;
+    gl_FragDepth = gl_FragCoord.z;
 }
Index: renderer/backend/DepthStage.cpp
===================================================================
--- renderer/backend/DepthStage.cpp	(revision 9322)
+++ renderer/backend/DepthStage.cpp	(working copy)
@@ -66,7 +66,7 @@
 	uint32_t scissor[4];
 	uint64_t textureHandle;
 	float alphaTest;
-	float padding;
+	float offsetRawZ;
 };
 
 DepthStage::DepthStage( DrawBatchExecutor* drawBatchExecutor )
@@ -288,6 +288,12 @@
 	CalcScissorParam( params.scissor, surf->scissorRect );
 	params.alphaTest = -1.f;
 
+	params.offsetRawZ = 0.0f;
+	const idMaterial *shader = surf->material;
+	if ( shader->TestMaterialFlag( MF_POLYGONOFFSET ) ) {
+		params.offsetRawZ = shader->GetPolygonOffset() * r_offsetRawZ.GetFloat();
+	}
+
 	if ( surf->material->GetSort() == SS_SUBVIEW ) {
 		// subviews will just down-modulate the color buffer by overbright
 		params.color[0] = params.color[1] = params.color[2] = 1.0f / backEnd.overBright;
Index: renderer/draw_common.cpp
===================================================================
--- renderer/draw_common.cpp	(revision 9322)
+++ renderer/draw_common.cpp	(working copy)
@@ -370,6 +370,12 @@
 	default:
 		programManager->oldStageShader->Activate();
 		OldStageUniforms *oldStageUniforms = programManager->oldStageShader->GetUniformGroup<OldStageUniforms>();
+
+		oldStageUniforms->offsetRawZ.Set(0.0f);
+		if ( pStage->privatePolygonOffset || surf->material->TestMaterialFlag( MF_POLYGONOFFSET ) ) {
+			oldStageUniforms->offsetRawZ.Set(r_offsetRawZ.GetFloat());
+		}
+
 		switch ( pStage->vertexColor )	 {
 		case SVC_IGNORE:
 			oldStageUniforms->colorMul.Set( zero );
Index: renderer/glsl.h
===================================================================
--- renderer/glsl.h	(revision 9322)
+++ renderer/glsl.h	(working copy)
@@ -202,6 +202,7 @@
 	DEFINE_UNIFORM( float, screenTex );
 	DEFINE_UNIFORM( vec4, colorMul );
 	DEFINE_UNIFORM( vec4, colorAdd );
+	DEFINE_UNIFORM( float, offsetRawZ );
 };
 
 GLSLProgram* GLSL_LoadMaterialStageProgram(const char *name);
Index: renderer/RenderSystem_init.cpp
===================================================================
--- renderer/RenderSystem_init.cpp	(revision 9323)
+++ renderer/RenderSystem_init.cpp	(working copy)
@@ -122,8 +122,9 @@
 idCVar r_useFrustumFarDistance( "r_useFrustumFarDistance", "0", CVAR_RENDERER | CVAR_FLOAT, "if != 0 force the view frustum far distance to this distance" );
 idCVar r_logFile( "r_logFile", "0", CVAR_RENDERER | CVAR_INTEGER, "number of frames to emit GL logs" );
 idCVar r_clear( "r_clear", "2", CVAR_RENDERER | CVAR_ARCHIVE, "force screen clear every frame, 1 = purple, 2 = black, 'r g b' = custom" );
-idCVar r_offsetFactor( "r_offsetfactor", "-2", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "polygon offset parameter" ); // #4079
-idCVar r_offsetUnits( "r_offsetunits", "-0.1", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "polygon offset parameter" ); // #4079
+idCVar r_offsetFactor( "r_offsetfactor", "0", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "glPolygonOffset 'factor' parameter" ); // #4079
+idCVar r_offsetUnits( "r_offsetunits", "-1", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "glPolygonOffset 'units' parameter" ); // #4079
+idCVar r_offsetRawZ( "r_offsetrawz", "-0.1", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "offset every fragment by X doom units away from eye" );
 idCVar r_shadowPolygonOffset( "r_shadowPolygonOffset", "-1", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "bias value added to depth test for stencil shadow drawing" );
 idCVar r_shadowPolygonFactor( "r_shadowPolygonFactor", "0", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "scale value for stencil shadow drawing" );
 idCVar r_frontBuffer( "r_frontBuffer", "0", CVAR_RENDERER | CVAR_BOOL, "draw to front buffer for debugging" );
Index: renderer/tr_local.h
===================================================================
--- renderer/tr_local.h	(revision 9322)
+++ renderer/tr_local.h	(working copy)
@@ -921,6 +921,7 @@
 extern idCVarInt r_swapInterval;			// changes wglSwapIntarval
 extern idCVar r_offsetFactor;			// polygon offset parameter
 extern idCVar r_offsetUnits;			// polygon offset parameter
+extern idCVar r_offsetRawZ;
 extern idCVar r_singleTriangle;			// only draw a single triangle per primitive
 extern idCVar r_logFile;				// number of frames to emit GL logs
 extern idCVar r_clear;					// force screen clear every frame
4634_temp_offsetrawz.patch (8,074 bytes)   
duzenko

duzenko

29.04.2021 08:57

developer   ~0013932

Last edited: 29.04.2021 08:59

View 4 revisions

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?
stgatilov

stgatilov

29.04.2021 15:09

administrator   ~0013934

"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 =)
duzenko

duzenko

29.04.2021 15:50

developer   ~0013935

>> "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

Issue History

Date Modified Username Field Change
14.10.2017 07:46 stgatilov New Issue
14.10.2017 07:48 stgatilov File Added: broken_ambient_1.jpg
14.10.2017 07:48 stgatilov File Added: broken_ambient_2.jpg
14.10.2017 07:50 stgatilov Note Added: 0009466
14.10.2017 12:13 duzenko Note Added: 0009468
14.10.2017 12:13 duzenko File Added: Untitled.jpg
14.10.2017 12:14 duzenko Note Edited: 0009468 View Revisions
14.10.2017 12:15 duzenko File Deleted: Untitled.jpg
14.10.2017 12:16 duzenko File Added: Untitled.jpg
14.10.2017 12:32 stgatilov Note Added: 0009469
14.10.2017 12:33 stgatilov Note Added: 0009470
14.10.2017 12:34 duzenko Note Added: 0009471
14.10.2017 12:35 duzenko Note Edited: 0009471 View Revisions
14.10.2017 12:35 stgatilov Note Added: 0009472
14.10.2017 12:36 duzenko Note Edited: 0009471 View Revisions
14.10.2017 12:36 duzenko Note Added: 0009473
14.10.2017 12:39 stgatilov Note Added: 0009474
14.10.2017 12:40 stgatilov Note Added: 0009475
15.10.2017 10:16 duzenko Note Added: 0009480
15.10.2017 10:17 duzenko Note Edited: 0009480 View Revisions
15.10.2017 10:29 duzenko Note Edited: 0009480 View Revisions
15.10.2017 10:38 duzenko Note Edited: 0009480 View Revisions
15.10.2017 10:40 duzenko Note Edited: 0009480 View Revisions
15.10.2017 15:23 VanishedOne Note Added: 0009481
15.10.2017 15:25 VanishedOne Note Edited: 0009481 View Revisions
15.10.2017 16:27 stgatilov Note Added: 0009482
15.10.2017 16:40 duzenko Note Added: 0009483
15.10.2017 17:30 VanishedOne Note Added: 0009484
15.10.2017 17:43 VanishedOne Note Edited: 0009484 View Revisions
11.11.2017 15:35 stgatilov File Added: PatentlyDangerous_BrightnessIssue.jpg
11.11.2017 15:37 stgatilov Note Added: 0009569
11.11.2017 18:52 duzenko Note Added: 0009578
12.11.2017 21:46 VanishedOne Note Added: 0009587
14.11.2017 16:59 stgatilov Note Added: 0009614
14.11.2017 19:43 duzenko Note Added: 0009619
14.11.2017 19:43 duzenko Note Edited: 0009619 View Revisions
14.11.2017 19:46 duzenko Note Edited: 0009619 View Revisions
14.11.2017 19:48 duzenko Note Edited: 0009619 View Revisions
31.12.2017 07:24 stgatilov Relationship added related to 0004079
31.12.2017 07:41 stgatilov Note Added: 0009947
31.12.2017 07:42 stgatilov Note Edited: 0009947 View Revisions
28.03.2018 08:37 user81 Note Added: 0010173
28.03.2018 09:31 duzenko Note Added: 0010196
28.03.2018 09:32 duzenko Note Edited: 0010196 View Revisions
21.03.2020 17:47 stgatilov Product Version SVN => TDM 2.05
21.03.2020 17:47 stgatilov Target Version => TDM 2.09
21.03.2020 17:47 stgatilov Assigned To => stgatilov
21.03.2020 17:47 stgatilov Status new => assigned
05.12.2020 12:35 stgatilov Target Version TDM 2.09 => TDM 2.10
18.02.2021 12:00 stgatilov Summary Inn Business: ambient light on a rug in tavern is not smooth => Decal depth fighting (Inn Business: "rug in tavern is not smooth")
28.03.2021 05:06 stgatilov Note Added: 0013812
28.03.2021 05:16 stgatilov Note Edited: 0013812 View Revisions
28.03.2021 05:21 stgatilov Note Added: 0013813
28.03.2021 05:22 stgatilov Product Version TDM 2.05 => TDM 2.04
28.03.2021 06:48 stgatilov Note Added: 0013814
28.03.2021 09:37 duzenko Note Added: 0013815
28.03.2021 11:41 stgatilov Note Added: 0013816
09.04.2021 13:57 stgatilov Relationship added related to 0005580
09.04.2021 17:44 stgatilov Note Added: 0013830
09.04.2021 17:46 stgatilov Note Edited: 0013830 View Revisions
10.04.2021 04:10 stgatilov Note Edited: 0013830 View Revisions
10.04.2021 04:11 stgatilov Note Edited: 0013830 View Revisions
28.04.2021 17:02 stgatilov Note Added: 0013931
28.04.2021 17:02 stgatilov File Added: 4634_temp_offsetrawz.patch
28.04.2021 17:02 stgatilov Note Edited: 0013931 View Revisions
29.04.2021 08:57 duzenko Note Added: 0013932
29.04.2021 08:58 duzenko Note Edited: 0013932 View Revisions
29.04.2021 08:58 duzenko Note Edited: 0013932 View Revisions
29.04.2021 09:00 duzenko Note Edited: 0013932 View Revisions
29.04.2021 15:09 stgatilov Note Added: 0013934
29.04.2021 15:50 duzenko Note Added: 0013935