 |
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 |
|
|
|
|
|
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. |
|
|
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). |
|
|
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... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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\dmap_tjunc_stlucia_rope.map, I don't see any holes in rope. I don't know what happened, but it no longer justifies disabling the snapping. |
- Anonymous
