View Issue Details

IDProjectCategoryView StatusLast Update
0005486The Dark ModCodingpublic10.04.2021 04:29
Reporterstgatilov Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityalways
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:
  https://forums.thedarkmod.com/index.php?/topic/20692-devs-209-is-branched-out/&do=findComment&comment=455282
TagsNo tags attached.

Relationships

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 

Activities

stgatilov

stgatilov

05.01.2021 18:19

administrator   ~0013380

Last edited: 05.01.2021 18:19

View 2 revisions

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

Revision: 8558
Author: stgatilov
Date: 2 февраля 2020 г. 23:32:15
Message:
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
stgatilov

stgatilov

05.01.2021 18:20

administrator   ~0013381

stgatilov

stgatilov

07.01.2021 05:45

administrator   ~0013416

Last edited: 07.01.2021 11:27

View 3 revisions

Added test map to SVN: maps\test\dmap_tjunc_nhat_fence.map
Added test map to SVN: maps\test\dmap_tjunc_newjob_sign.map
Added test map to SVN: maps\test\dmap_tjunc_stlucia_rope.map

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):
  https://bugs.thedarkmod.com/view.php?id=5137#c12173
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.
stgatilov

stgatilov

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

stgatilov

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 dmap_tjunc_nhat_fence.map and dmap_tjunc_newjob_sign.map perfectly.

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

stgatilov

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

stgatilov

09.04.2021 17:52

administrator   ~0013831

Last edited: 09.04.2021 17:52

View 2 revisions

Looking at comment https://bugs.thedarkmod.com/view.php?id=5137#c12173:
  "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\dmap_tjunc_stlucia_rope.map
So I was wrong thinking that holes happen because of collinear vertices removal: it is the goddamn vertex snapping in T-junctions removal.
stgatilov

stgatilov

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\dmap_tjunc_stlucia_rope.map is fixed now.

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 View Revisions
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 View Revisions
07.01.2021 11:27 stgatilov Note Edited: 0013416 View Revisions
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 View Revisions
10.04.2021 04:29 stgatilov Note Added: 0013832