View Issue Details

IDProjectCategoryView StatusLast Update
0005486The Dark ModCodingpublic17.09.2022 09:04
Reporterstgatilov Assigned Tostgatilov  
Status resolvedResolutionfixed 
Product VersionTDM 2.08 
Target VersionTDM 2.10Fixed in VersionTDM 2.10 
Summary0005486: dmap: close vertices due to numeric errors, and bloomed sparklies
DescriptionDmap seems to generate very close vertices, and consequently sliver triangles.
These triangles have different attributes (normals?), hence specular highlight is very strong on them.
They look like "sparklies".

If bloom and 64-bit color are enabled, then sparklies turn into large over-bright spots.
Steps To Reproduce1) Choose NHAT fm.
2) Run: dmap politics.
3) Now: map politics
4) From starting area, go ahead and turn left on the first occasion.

The fence is bad: it has very close vertices, and very sliver triangles.
And probably also sparklies.
Additional InformationOriginally reported here:
TagsNo tags attached.


related to 0005137 resolvedstgatilov Dmap optimization breaks rain patches 
related to 0004957 resolvedstgatilov Snow and rain particles stopping on brushes 
related to 0005580 resolvedstgatilov Dmap : better windings precision 




05.01.2021 18:19

administrator   ~0013380

Last edited: 05.01.2021 18:19

Found that svn rev 8558 broke it (TDM 2.08):

Revision: 8558
Author: stgatilov
Date: 2 февраля 2020 г. 23:32:15
0004957. Reduce chance that close vertices would be snapped to different points in T-junctions removal.

Note the T-junctions removal algorithm also serves as a generic mesh cleaner.
It snaps triangle vertices exactly to each other, so that further mesh processing could work reliably.

The problem is that when vertex is snapped to some grid point, its coordinate is rounded to the nearest of two snap points.
If model has vertices exactly at the middle between snap points, then they get snapped into different directions depending on roundoff error.
Having vertex with coordinate (2*integer+1)/64 is quite likely in a real model.
The fix is to shift coordinate slightly, so that it gets rounded down in such cases.

Modified : /trunk/tools/compilers/dmap/tritjunction.cpp


05.01.2021 18:20

administrator   ~0013381



07.01.2021 05:45

administrator   ~0013416

Last edited: 07.01.2021 11:27

Added test map to SVN: maps\test\
Added test map to SVN: maps\test\
Added test map to SVN: maps\test\

The fence from "No Honor Among Thieves" uses custom material.
When extracting test map, I replaced it with stock material using the same textures.
As the result, I don't see such bloom-magnified plasma particles =)
Instead I see small bright sparklies running along edges of the fence.

The sign from "New Job" is also added as test map.
It is the entity which has mentioned related to the original "fix" (which broke this fence):
The problem is the same: sliver triangle on the top of the sign.
It is even displayed as bright white line, supposedly showing the same problem as the fence.

The last test map is from "Saint Lucia".
It has a rope right in front of the player, which has a very sliver hole in it.
It seems that the rope is composed of brushes, and I guess this hole happens due to close input vertices snapped to different hash vertices.


08.01.2021 04:53

administrator   ~0013426

Regarding the rope: it is hardly fixable.

The problem happens due to "optimize" algorithm removing collinear vertices.
This algorithm works independently on every planar piece of the entity, and can remove almost collinear vertices, shifting boundary by up to 0.1.
It is possible that closed triangulation becomes non-closed due to this shift, introducing sliver holes of very low width.

I have no ideas how to fix it (disabling optimization would help, but is hardly an option).


10.03.2021 17:25

administrator   ~0013771

Committed the changes:
  r9191 Reverted svn rev 8558 (fixing dmap-generated sparklies). Better fix is provided in next commits.
  r9192 Minor preparations.
  r9193 Added two new algorithms for vertex merging, one of them is the new default.

The core stuff is of course in r9193.
There are three algorithms instead of one now.
The two new algorithms both solve tests and perfectly.

I had to make rather nasty signature changes for the last algorithm.
Hopefully it won't be a problem for future developers...


10.03.2021 17:30

administrator   ~0013772

Copying commit message or r9193:

The behavior depends on dmap_fixVertexSnappingTjunc cvar.
With value 0 (old), vertices are merged if they belong to the same cell.
  As the result, very close vertices near cell boundary could remain unmerged (and still very close).
With value 1 (new), vertices are merged greedily to each other by distance.
  As the result, output vertices are surely at distance > 1/32 from each other.
  However, the outcome depends on the order of vertices, plus two very close vertices can be snapped away from each other.
With value 2 (new & default), any two vertices closer than 1/32 from each other are merged to the same vertex.
  To ensure such behavior, graph of close vertices is built, and each connected component is compressed into one vertex.
  This behavior should be order-independent.


09.04.2021 17:52

administrator   ~0013831

Last edited: 09.04.2021 17:52

Looking at comment
  "Then all vertices of the mesh are "snapped" to the points of this grid. The snapping is imaginary, the coordinates of mesh vertices don't change in normal case. But if several vertices get snapped to the same grid point, then one of the vertices is stitched precisely to the other."
It seems I believed that the vertices are only snapped in T-junction removal when they are close to each other =(

The truth is: vertices are always snapped to coordinates like (Z+0.5)/32.

I bumped into it while working on decals depth fighting problem (0004634).
Fun fact is: if I disable this snap-by-default behavior, then the rope in Saint Lucia gets fixed.
I mean the test case: maps\test\
So I was wrong thinking that holes happen because of collinear vertices removal: it is the goddamn vertex snapping in T-junctions removal.


10.04.2021 04:29

administrator   ~0013832

Committed in svn rev 9239.

Now mandatory vertex snapping is disabled by default.
It can be restored by setting "dmap_disableCellSnappingTjunc 0".
Of course, merging of close vertices is done anyway.

The test\ is fixed now.


17.09.2022 09:04

administrator   ~0015254

I reverted the previous commit, setting dmap_disableCellSnappingTjunc back to 0 in svn rev 10118.

The reason is that in some cases, we get an explosion in the number of triangles (most likely sliver) without snapping.
More detailed explanation is given in 0006085.

Also, now that I test maps\test\, I don't see any holes in rope.
I don't know what happened, but it no longer justifies disabling the snapping.

Issue History

Date Modified Username Field Change
05.01.2021 18:18 stgatilov New Issue
05.01.2021 18:18 stgatilov Status new => assigned
05.01.2021 18:18 stgatilov Assigned To => stgatilov
05.01.2021 18:19 stgatilov Note Added: 0013380
05.01.2021 18:19 stgatilov Note Edited: 0013380
05.01.2021 18:20 stgatilov Note Added: 0013381
05.01.2021 18:20 stgatilov File Added: nhat3_redmapped_flashes.jpg
05.01.2021 18:20 stgatilov Relationship added related to 0005137
06.01.2021 04:28 stgatilov Target Version TDM 2.09 => TDM 2.10
06.01.2021 05:12 stgatilov Relationship added related to 0004957
07.01.2021 05:45 stgatilov Note Added: 0013416
07.01.2021 05:59 stgatilov Note Edited: 0013416
07.01.2021 11:27 stgatilov Note Edited: 0013416
08.01.2021 04:53 stgatilov Note Added: 0013426
10.03.2021 17:25 stgatilov Note Added: 0013771
10.03.2021 17:26 stgatilov Status assigned => resolved
10.03.2021 17:26 stgatilov Resolution open => fixed
10.03.2021 17:26 stgatilov Fixed in Version => TDM 2.10
10.03.2021 17:30 stgatilov Note Added: 0013772
09.04.2021 17:13 stgatilov Relationship added related to 0005580
09.04.2021 17:52 stgatilov Note Added: 0013831
09.04.2021 17:52 stgatilov Note Edited: 0013831
10.04.2021 04:29 stgatilov Note Added: 0013832
17.09.2022 09:04 stgatilov Note Added: 0015254