Jump to content
The Dark Mod Forums

Invisible brush of death: its doing my head in.


Bikerdude

Recommended Posts

Had this issue in Melans new map and i gfot around the issue bu exported everyting around the effected location as prefabs, created new map imported said prefabs and now more "IBOD"

 

I have discovered that this IBOD issue is whats causing the freezing issue pplayers have reported in the NHAT campaign, specifically 'Politics', in the Cathedral, to the left of the alter. I have done 4 prefab-exports to a new maps and the vbloody issue persists. So now I am trying a crude brute force approach by building still in that location and preventing the player from going there.

 

After wasting a day on this I would really, really like to find WTF is causing these fucking IBOD's

 

<_<

Link to comment
Share on other sites

I got the freeze in three different places inside the cathedral.

 

Once to the left of the altar.

 

Once to the right.

 

And once above the entry door, while noclipping around the area trying to figure out if the problem was TDM's or the map's. I was passing through the opening between the upper balcony (where the guard patrols) and the main central area.

Link to comment
Share on other sites

It's the title of the thread, Invisible Brushes of Death.

 

I think he's talking about when you have, e.g., slivers and the rendering barfs on a brush so it's invisible and you have weird lighting artifacts. That's the same name I used for that situation, anyway, invisible walls of death. I can imagine how it contributes to the freezing because it'll open all the leafs around it and render everything.

 

In my experience, it's small brushwork like slivers, overlaps, wedges, and tiny gaps around the seam of the "death" that make it happen.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

I wonder if there was a rounding error in the export or import somewhere and some little piece of it got a little off the grid, effectively making that situation or something like it. That's the best I can think of.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

maybe its a curved patch mesh intersecting a visportal, and therefore chopping it up into too many segments, I usually find that unless you turn all patch mesh work that intersects a visportal into a func_static or gets near a visportal then the game will freeze up.

Link to comment
Share on other sites

Patches should not cause additional intersections, as they are not sealing.

 

@Biker: MAybe it's me, but I do not completely get what those brushes of death are. Can you explain the problem a bit more in detail, please?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

All of those threads point to dmapping problems that caused visual artefacts. This causes a freeze of a few seconds. Biker, what have you spotted that suggests it's the same problem?

 

I didn't find anything obviously helpful in running round the room, but I'll jot down what I did see in case it gives a clue to someone.

The engine seems to be doing a lot of work clipping light volumes during the freeze, but maybe that's normal behavior. I don't have a pdb file for the release engine and I can only build it in debug mode so I haven't formally profiled the problem, but I paused the code a good 25 times during a freeze and on all but two hits the code was in the same subroutine clipping light vols. Not sure that sheds any light on the problem.

 

I got four freezes in the time i spent running round, none them ground level. All four were when I was climbing through upper storey window (different ones), and therefore crossing a visportal. Those upper window VPs never seemed to close. Or do they do something when off screen?

Link to comment
Share on other sites

@Biker: MAybe it's me, but I do not completely get what those brushes of death are. Can you explain the problem a bit more in detail, please?

I mean the game is freezing when the player isnt touching or intersecting anything in a specific location.

  • All of those threads point to dmapping problems that caused visual artefacts. This causes a freeze of a few seconds. Biker, what have you spotted that suggests it's the same problem?
  • I got four freezes in the time i spent running round, none them ground level. All four were when I was climbing through upper storey window (different ones), and therefore crossing a visportal. Those upper window VPs never seemed to close. Or do they do something when off screen?

  • Mine is just freezing.
  • Im gonna nuke all the VP's in that room and see if it cures it.

Link to comment
Share on other sites

  • 3 months later...

Well young SteveL found the culprit, it was having multiple VP in the same plane in the cathedral, in NHAT that was causing the freeze. In short the game engine was getting confused and mapper should avoid having multiple VP's in line with each other.

 

Does that mean "in line which each other in the entire map" e.g. three rooms over, or just "in the same room"? Also, it would be good to find out if this is a new issue (e.g. some of the door handling code freaks out), or an old issue from the D3 engine days.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Does that mean "in line which each other in the entire map" e.g. three rooms over, or just "in the same room"? Also, it would be good to find out if this is a new issue (e.g. some of the door handling code freaks out), or an old issue from the D3 engine days.

 

The second option, to both questions. The aligned VPs have to be open to trigger the freeze, so it's not a whole-map problem, and to be really problematic they have to separate the same 2 visleafs. As for recent vs old, I think it's old, though I haven't tried to check. There are 2 bugfixes combining to produce the freeze and they're both in the renderer front end and they don't look new. I suspect we inherited them.

 

The part of the renderer that's choking is idRenderWorldLocal::FloodViewThroughArea_r, which discovers all the light/surface interactions for the back end.

 

That's a recursive function that goes through every visleaf reachable by an open VP, and clips the surfaces and models and lights in the area to the player's view. It starts with the player's wide view frustum in his or her current visleaf, and checks all portals in the area to see whether they are visible in that frustum. If it finds a (partially) visible VP to another area, it extends the view frustum into that area, clipping it by the edges of the VP it has it pass through to get there, and then recurses to find any VPs in that visleaf that are viewable within the clipped frustum, and so forth. Normally it'll recurse only to a depth of 1-2 and it won't have to handle cycles. But where it finds cycles, it doesn't quit: there could be different parts of a long dining table visible through 2 different VPs, for example, so it fully explores both paths even if it hits the same visleaf twice. NB there's no distance checking involved. Portal #2 is considered to be behind portal #1 if and only if portal #2 is contained in the view frustum after it's been clipped by portal #1.

 

Problem bugfix #1 is that if the player is within 1 doom units of the VP plane, the view frustum doesn't get clipped when it passes through that portal. That one's commented: the comment says that epsilon errors cause the region to vanish when in view without the fix. But it could be wrong--I'm not sure. The comment talks about the player being close to the VP surface, but the code actually tests whether the player is close the *plane* of the VP, and it uses an ambiguously named "distance" variable set earlier in the function, so it's not clear whether it's doing exactly what was intended.

 

Bugfix #2 is that when the player is standing very close to the plane of the VP (within 0.1 doom units), the code decides that he can see through the visportal from both sides simultaneously.

 

The problem comes when you have several VPs in a single plane connecting the same two visleafs, and when the player can stand in that plane while the VPs are open. There's no absolute distance checking, and the player's view doesn't get clipped when passing through those VPs, so every VP is judged to be visible through every other VP and all combinations have to be explored. If you have 5 VPs in line between the same 2 visleafs like in NHAT cathedral, each providing a view through both sides at once, and the player can get in line with them without any closing, that's 5x2 different views through a VP in any order = !10 = 3.5M VP paths that can be explored, and the entities and world models get their interactions checked that many times. In NHAT, not all the VPs can be in the original view frustum at once, but I have logs showing it reclipping the cathedral contents between 0.5M and 1.5M times per freeze. When not freezing, that number is between 1 and 5. And the logs show the portals being passed through in every possible ordering and combination. You don't get the combinatorial explosion where some of the VPs are closed, or embedded in a building where the player can't get into the wall, or where there are different visleafs on one side of the wall or other. And it doesn't happen when noclipping because most of the renderer front end, including this bit, is skipped when the player isn't in a visleaf: everything gets rendered without these performance optimizations. It looks fixable in the code, but I fear we'd need a *lot* of testing after messing with something so low-level, so it might be a better use of time just to fix the odd case where it shows up.

Link to comment
Share on other sites

Just to be clear, does this only happen when they share the same plane, or would it happen any time 5+ VPs separate two visleafs? i.e. would this fix it or not? It's easy to "merge" VPs into one with a row of columns, but not so much if each VP has a corresponding door.

Link to comment
Share on other sites

Lots of interesting information here, good to know.

"My milkshake bringeth all ye gentlefolk to the yard. Verily 'tis better than thine, I would teach thee, but I must levy a fee."

"When Kleiner showed me the sky-line of New York I told him that man is like the coral insect—designed to build vast, beautiful, mineral things for the moon to delight in after he is dead."

https://soundcloud.com/paralytik

 

Link to comment
Share on other sites

The more I think about it, the more I think that bugfix #1 mentioned above isn't doing quite what was intended, and that we should have a go at fixing the issue in the game code.

 

What I'm calling "bugfix #1" is the rule that got put in with this comment:

   // if we are very close to the portal surface, don't bother clipping
  // it, which tends to give epsilon problems that make the area vanish

 

And it uses a distance variable that got set in a different part of the code. But the distance being checked is the player's distance from the portal's plane, not the portal itself. That could be a simple mistake.

 

Now it makes sense not to try to clip the player's view using a visportal when he or she has their nose right up against it. It's like when you stand in a doorway, the doorframe doesn't obstruct your view. But because the code is testing the plane distance instead of the portal distance, you get some odd effects including the freezes in NHAT and, Biker tells me, an earlier version of PD2 where the arches had separate VPs.

 

Here's a contrived test map to show what I'm talking about. The front VP (portal 1) is in a wall that recesses a bit on the right, so it'll let the player get in line with the VP. When the player is in front of the three VPs like in this picture, they behave normally. Two are open and the one at the back is closed because it can't be seen though portal 2:

 

 

 

Here's what I suspect the bugfix probably meant to handle: The player is up against portal 1 and doesn't need his or her view restricting by it:

 

 

 

The VPs still behave normally when the player is at an angle. The player's view is clipped properly and only a narrow slice of room 2 has to be rendered. Portal 3 isn't visible at all because portal 2 is closed:

 

 

 

But when the player gets in line with portal 1, the portals behind it open. The player's view isn't clipped at all by portal 1 so most of the room behind is rendered, and portal 3 that shouldn't even be considered opens up too. And because new VPs to flow through are discovered simply by checking for what VPs in the new area are caught by the player's view after flowing through a portal, the game will think that portal 1 can be seen through itself. It doesn't know that the player's view didn't get clipped at all by portal 1. Now there's already a safeguard in place to stop infinite loops caused by portals being seen through themselves, but it doesn't stop multiple portals in the same plane from being able to "see" one another irrespective of their distance or what order they're in, and that allows for millions of combinations given half a dozen portals. That's what causes the freezes as well as the extra stuff being rendered unnecessarily in this example. This is what I suspect the fix didn't mean to do:

 

 

 

If we try this fix in svn, it'll only affect a couple of lines of code in one place. Basically replace the plane-distance check with a distance check on the portal itself. So if we find bugs around VPs, we can easily undo it. What do people think?

Edited by SteveL
Link to comment
Share on other sites

a distance check on the portal itself
Keep in mind that I'm completely uninformed, but assuming "distance to portal" is measured from its center, wouldn't that create difference in behavior between thin and wide portals (think VPing streets)?

 

Also, a more common example (than a recessed wall) would just be a corner of a building, like this.

Edited by chedap
Link to comment
Share on other sites

Keep in mind that I'm completely uninformed, but assuming "distance to portal" is measured from its center, wouldn't that create difference in behavior between thin and wide portals (think VPing streets)?

Yes it would, but I've accounted for that in the tests I'm doing now. I've left the distance-to-plane check in place for efficiency, and only if that passes, I'm trying a second check on portal distance. So we only have to worry about the cases where the player is in line with the portal, because otherwise the dist-to-plane check will already have failed. By "distance to portal" I mean, distance from eye position to centre of portal minus the radius of the portal, which works when the player is in line. One bit of good news: turns out the the sideways portal doesn't just clip the view into a very narrow slice. it chokes it off completely, so the visleaf the other side doesn't get checked by the renderer at all, same as if the portal were closed.

 

Also, a more common example (than a recessed wall) would just be a corner of a building, like this.

Agreed, that could well be the place this happens most often, where there's no actual door to close the portal.

Link to comment
Share on other sites

While you are looking at portal changes, any chance you could look into implementing "antiportals"

 

http://udn.epicgames...ntiportals.html

 

Eg. Invisible brush volumes that tell the renderer "do not render anything behind me when in view".

 

I suppose func_portals serve this same purpose but have more overhead (not as low level).

 

(an old Doom 3 mapper complaining that antiportals don't exist in Doom 3: http://www.celephais.net/board/view_thread.php?id=4&start=13826&end=13850 )

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

While you are looking at portal changes, any chance you could look into implementing "antiportals" http://udn.epicgames...ntiportals.html Eg. Invisible brush volumes that tell the renderer "do not render anything behind me when in view". I suppose func_portals serve this same purpose but have more overhead (not as low level). (an old Doom 3 mapper complaining that antiportals don't exist in Doom 3: http://www.celephais.net/board/view_thread.php?id=4&start=13826&end=13850 )

 

This sounds like a rather interesting solution to a common (huge outdoor scenes) problem - albeit in TDM missions it is probably less common. Can you please open a bugtracker for it with the relevant links (please add excerpts in case the links go dead) and link it also to this thread?

 

Even if nobody can add it, having it documented and referenced is good.

 

From a technical standpoint, anti-portals might be achiveable with a flag and a few negated tests, but it might also be that the engine internals a a huge mess and adding another type of portal was never intended :) SteveL or Grayman can probably say much better how the status is.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

The more I think about it, the more I think that bugfix #1 mentioned above isn't doing quite what was intended, and that we should have a go at fixing the issue in the game code. What I'm calling "bugfix #1" is the rule that got put in with this comment:
 // if we are very close to the portal surface, don't  So if we find bugs around VPs, we can easily undo it. What do people think? 

 

Wow, what an informative and well-documented post. Good work. I'd say put in the fix, and then lets test it. (Unless you haven't already :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...