View Issue Details

IDProjectCategoryView StatusLast Update
0005353The Dark ModFeature proposalpublic15.04.2021 22:19
ReporterGeep Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Target VersionTDM 2.10Fixed in VersionTDM 2.10 
Summary0005353: Feature: Finer-grained DMap Warning for "dropped" visportals
DescriptionDuring DMAP, warnings about visportal problems already provide some categorization (e.g., "dropped" vs "useless"). It is proposed, if technically feasible, to differentiate the "dropped" category further, into -
- "dropped (bad seal)"
- "dropped", all other cases
where "bad seal" means that some part of the visportal edge is not in worldspawn. (I'm not married to "bad seal" as a phrase... substitute any other you like.)

Ideally, the "bad seal" tag would be applied both to the console warning as shown, and incorporated into the filename of the corresponding pointfile. The reason for doing this is that the mapper could see at a glance which visportal failures are due to bad seals, and so prioritize the fixing of those. Oftentimes, fixing bad seals makes some of the other visportal warnings go away.
Additional InformationIt is recognized that, if the naming of pointfiles is modified, a system that cycles through pointfiles automatically in DR, instead of needing manual renaming, could be impacted by this.
TagsNo tags attached.


related to 0005129 resolvedstgatilov dmap: add diagnostics for visportal problems 




09.04.2021 16:31

administrator   ~0013828

Last edited: 09.04.2021 16:31

I think you should write what you mean by "all other cases".

The "dropped" message shows when there is the same area on the both sides of the visportal.
It is a problem in any case, since the portal has no effect in such case.

Do you suggest checking if visportal contacts some opaque geometry along all of its boundary?
And produce different message if it does?


11.04.2021 23:05

reporter   ~0013838

"Do you suggest checking if visportal contacts some opaque geometry along all of its boundary?
And produce different message if it does?"

Yes, that is the distinction I am making.

For instance, let's say there is a room with 2 doors. Door 1 has a perfect visportal. Door 2 has a bad visportal: one of its edges is not entirely in worldspawn.

I'd like Door 1's visportal to be tagged as "dropped", and Door 2's visportal to be tagged as "dropped (bad seal)".

There may be other reasons why Door 1 would be tagged as "dropped", for instance -
- I forgot to make a visportal for Door 2
- There's a leak in the room geometry
These are what I meant by "all other cases".


15.04.2021 14:10

administrator   ~0013849

Committed the improvement in svn rev 9280.
Followed some refactoring in svn rev 9281.

If some part of visportal's boundary does not contact opaque geometry of other visportal, I call it "leaky".


15.04.2021 14:10

administrator   ~0013850

Last edited: 15.04.2021 14:11

Initially I tried to honestly check whether all edges of the visportal contact opaque geometry or another visportal.

The problem with such approach is that when dropped visportal is detected, we only have a piece of it (cut our by BSP tree).
This piece may have all of its edges contacting the other pieces of the same visportal, so it would be detected as non-leaky.
However, they can be many more pieces, some of them being leaky.
So we have to collect all pieces of the visportal, and check all their non-internal edges at once.

Also, visportal can be split in opaque geometry into several separate visportals.
One of them can be leaky, the other not.
It seems that such split visportals are handled as separate visportals by diagnostics right now.
So we also have to detect connected components of the visportal pieces and handle then separately.

Obviously, it gets too complicated this way.


15.04.2021 14:16

administrator   ~0013851

Then I decided to use the "dual" approach which has already served us well.

Instead of checking visportal boundary, I try to find a special cycle going through it.
That's the same cycle which is reported for every dropped visportal, but with additional constraint:
   all nodes in the part must touch the dropped visportal either by face or by edge
Such a cycle must always go along the visportal, so it can even show where the contact is missing.

Even if this is not 100% correct, it seems to work well on two FMs I tried, and it is easy to implement.


15.04.2021 14:17

administrator   ~0013852

Now reports look like this:
  WARNING:Portals [4101,4103] at (437 -952 1152) overlap
  saved fms\ac2\maps\ac2_portalO_437_m952_1152.lin (5 points)
  WARNING:Portal 1099 at (1036.5 493.5 15) dropped as leaky
  saved fms\ac2\maps\ac2_portalL_1036d5_493d5_15.lin (9 points)
  WARNING:Portal 4107 at (22 768 1136) dropped as leaky
  saved fms\ac2\maps\ac2_portalL_22_768_1136.lin (5 points)
  WARNING:Portal 4200 at (998 379.5 1148) dropped as leaky
  saved fms\ac2\maps\ac2_portalL_998_379d5_1148.lin (7 points)
  WARNING:Portal 4056 at (14 477 1136) dropped as leaky
  saved fms\ac2\maps\ac2_portalL_14_477_1136.lin (5 points)
  WARNING:Portal 4058 at (472 58 1157.5) dropped as leaky
  saved fms\ac2\maps\ac2_portalL_472_58_1157d5.lin (5 points)
  WARNING:Portal 1395 at (245 336 562) dropped

So the leaky portals have additional "as leaky" in the warning.
Also, non-leaky portals have letter 'D' in filename instead of 'L'.


15.04.2021 22:19

reporter   ~0013860

Wonderful. I'm making a note to myself to write this up for the wiki before the release of 2.10

Issue History

Date Modified Username Field Change
04.10.2020 16:55 Geep New Issue
09.04.2021 16:31 stgatilov Note Added: 0013828
09.04.2021 16:31 stgatilov Note Edited: 0013828
11.04.2021 23:05 Geep Note Added: 0013838
12.04.2021 02:34 stgatilov Assigned To => stgatilov
12.04.2021 02:34 stgatilov Status new => assigned
14.04.2021 15:26 stgatilov Relationship added related to 0005129
15.04.2021 14:10 stgatilov Note Added: 0013849
15.04.2021 14:10 stgatilov Note Added: 0013850
15.04.2021 14:10 stgatilov Note Edited: 0013850
15.04.2021 14:11 stgatilov Note Edited: 0013850
15.04.2021 14:16 stgatilov Note Added: 0013851
15.04.2021 14:17 stgatilov Note Added: 0013852
15.04.2021 14:17 stgatilov Status assigned => resolved
15.04.2021 14:17 stgatilov Resolution open => fixed
15.04.2021 14:17 stgatilov Fixed in Version => TDM 2.10
15.04.2021 14:18 stgatilov Target Version => TDM 2.10
15.04.2021 22:19 Geep Note Added: 0013860