View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005486||The Dark Mod||Coding||public||05.01.2021 18:18||10.04.2021 04:29|
|Product Version||TDM 2.08|
|Target Version||TDM 2.10||Fixed in Version||TDM 2.10|
|Summary||0005486: dmap: close vertices due to numeric errors, and bloomed sparklies|
|Description||Dmap 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 Reproduce||1) 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 Information||Originally reported here:|
|Tags||No tags attached.|
Found that svn rev 8558 broke it (TDM 2.08):
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
nhat3_redmapped_flashes.jpg (813,400 bytes)
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):
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.
|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|