 |
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? |
 |
"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". |
|
|
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". |
|
|
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. |
|
|
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. |
|
|
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'. |
|
|
Wonderful. I'm making a note to myself to write this up for the wiki before the release of 2.10 |
- Anonymous
