Ok, now THATs a gap

[Garreth]

agreed, off grid should automaticaly be deleted by darkradiant to prevent problems, had it happen a few times and had to copy my entire map to import in to a fresh grid, twice to be sure.

You can also see the same effect if you use noclip and go trough brushes, you will see flashes of the skybox and the void, it seems you clipped inside the table causing this effect.

[Springheel]

Ok, thanks for looking into it guys, I'll have to check those solutions in a bit.

 

I admit that I'm a bit confused, given the solutions, why the problem showed up in one build of TDM but didn't appear when I loaded the same map in a different build of TDM.

 

 

How do brushes get off grid in the first place?

[rebb]

It's showing up proper in a different TDM build ?

Probably worth looking into that too then.

 

Off-Grid can happen in different ways, non axial clipping for example.

[Springheel]

Remove the interior visportal and the problem isn't caused.

 

I tried this and confirm that it works.

 

 

There are a few very-offgrid brushes that sit on the border of the problem.

 

I'm going to try this, as I'd like to have that second visportal there to improve performance if the player leaves the front door open. Can you point me in the right direction of where to look?

 

 

it's showing up proper in a different TDM build ?

 

Yes, which is what perplexed me so much. I have a fresh download of SVN in a different folder, so on the chance that it was being caused my my recent messing with caulk and skyportal materials, I copied the map file there, dmapped and ran it. The black wall wasn't present.

[RJFerret]

I'd like to have that second visportal there to improve performance if the player leaves the front door open.

 

!?

 

If the player leaves the front door open, both portals will be open when the player is in line of sight of them. If the player moves out of line of sight, both portals will close regardless of the door being open.

 

The only way to get the outer leaf to render if the player is out of sight of that open door, would be if there's another route around/accessible with line of sight, and an open portal (which was why I was wondering about that other room with the opening to the outside initially). But in that case, the extra visportal won't provide any benefit anyway...in fact technically it might open as well since the door one would be open.

 

If you want to keep the redundant visportal, simply move it within the hallway, which resolves the issue, but I believe it doesn't have the benefit you might think.

 

I believe the only effect two portals will have is extra attenuation of sound.

[Springheel]

If the player leaves the front door open, both portals will be open when the player is in line of sight of them. If the player moves out of line of sight, both portals will close regardless of the door being open.

 

It will cut off the tavern from being seen from outside the house when the door is open (or vice versa), depending on the angle. Putting two visportals instead of one can be really useful in certain situations. See Komag's explanation here: http://forums.thedar...post__p__333432

[RJFerret]

Been there, done that video (back before I really learned about visportaling, and had experienced/tested how they work). There's better info somewhere that talks more about line of sight, and emphasizes the importance of angles/perpendicular aspects.

 

If you believe there's something in that video that shows a benefit, go for it. But, if you r_showportals 1, you'll find the extra third portal does nothing for you because of your good design.

 

Your extra visportal will always be open when there's line of sight between the furthest ones (the useful one at the exterior, and the perpendicular one entering the room you had issues in; or the useful one at the exterior, and the one at the end of the hallway). It's an issue of angle, and those three portals are all lined up (to the end of the hallway); or you have a perpendicular portal.

 

The simple test is seeing that the extra portal always opens while the exterior one remains closed, it's only if the exterior one would open prior to the extra one there'd be a benefit. In this case, the third portal does not help close the exterior one, it remains closed despite that extra one being open, until you get out of line of sight beyond the other visportals. The reason is because of where you placed the entrance to the room, further down the hall rather than right next to the entrance--the edge of that wall (with it's visportal) is what closes your exterior visportal, not the extra third portal (which is open for longer because it's closer and maintains line of sight longer).

 

Previous to this thread I would have said, go for it, it won't hurt anything, but as we witnessed, in this case, it actually did (but is easily resolved by shifting it if you still really want to keep it). :-)

[RJFerret]

Putting two visportals instead of one can be really useful in certain situations.

 

Sorry I didn't point this out in my lengthy previous, you are placing three, you already have two, and are putting an extra inbetween them, that's why it's not serving any useful purpose here that I see.

 

PS: Watch the video you linked starting at 9:30 for a verbal explanation of why, he says the same thing I am about angle.

Edited February 2, 2014 by RJFerret

[Springheel]

You probably know more about portals than I do. You're right that the second (third) one is kind of redundant, given the angle of the tavern entrance.

 

Snapping the diagonal ceiling brushes to grid is another way of solving the issue, oddly enough. Seems like both they AND the visportal have to be there to cause the problem. Addressing either one fixes it.

[RJFerret]

That makes sense to me, that's why I started with tracking down leaks to get the problem to occur. Since the visportals create separate leafs, when those leak internally, then a portal closes so that leaf isn't rendered, the geometry disappears for you even if it's in view I believe.

 

That's why we couldn't see it to begin with, when the portal was closing, the leaks to the outside meant that leaf was still being rendered for us, since we were effectively in that (huge) combined leaf.

 

What's curious to me is what condition of internal leaks causes a portal to not close as expected, versus behave like this one, create a leaf that extends into view.

 

There was someone newer recently who was asking if there was a command to show leafs, I'm thinking that would be very useful for stuff like this and a great way to expose internal leaks in lieu of using the location system and colored ambient light or sound or whatnot.

[Springheel]

That makes sense to me, that's why I started with tracking down leaks to get the problem to occur.

 

I don't quite understand this, as I had already tested the pub for internal leaks and thought that I had closed them all up. There's not still the bug where points move when saving, is there?

 

By the way, let me say thanks to everyone for the help; I appreciate it. Lesson of the day...visportals are unpredictable and you should dmap and check your map each time you add some.

[Bikerdude]

There's not still the bug where points move when saving, is there?

 

It should only be effecting FS, not WS.

[RJFerret]

@Spring, I don't know. (Per most your quandaries.)

 

I'm not convinced the map we were looking at was an identical version to what you were (hence seeing different results until changing it).

 

The three leaks I plugged (didn't fix, just covered) were leading to the leaf outside of the building. One was a 8x8 tube extending between brushes, so not points shifting.

 

And for my part, you are welcome! :-) I obviously sank my teeth into it, and found it a fun puzzle to figure out. Our further discussion touching on line of sight also got me thinking about diagonal visportals, and I sectioned a couple spaces in my WIP with three diagonal ones quite nicely.

Edited February 3, 2014 by RJFerret

[Springheel]

Oh for christsake. I deleted the visportal on the main map, snapped everything to the grid--exactly what solved it in the tesmap--loaded the map up and the same problem is still there, along with the entire side of the building being see-thru.

[RJFerret]

OMG, yikes! :-( Condolences for the frustration.

[Moonbo]

It's probably off-grid brushwork somewhere else in the map. Overlapping or off-grid brushes seem to be the consistent item in all the disappearing brush issues you've been having.

Edited February 3, 2014 by Moonbo

[Springheel]

Well, I'll try just selecting everything within range and snapping it to the grid and see what that does. I guess it would take less time to recheck the whole building for internal leaks then keep chasing down new gaps. Very frustrating.

[Moonbo]

Yeah . After a few bizzare issues with BSP, I became very strict with making sure that I had as few overlapping brushes as possible and that everything was snapped to grid (if brushes overlap or are at a weird angle, I usually turn them into FS). After that my issues with the renderer crapping out on me went down significantly.

Edited February 3, 2014 by Moonbo

[demagogue]

For the record, this has happened to me so many times I gave it a name, the "Black walls of death", it's the first item in my FAQ, and it was actually (if you go back and look) one of the early issues I started the "Newbie DR Questions" thread with (it's solution), so it's been a known thing since before 1.0.

 

In every instance I had it (at least 3, I was a messy builder early on), the reason was because somewhere on the line of where the black wall starts (that is, everything behind that line will be black) is sliver-brushwork, either a small sliver jut-out or a small niche or some weird slivers where brushes meet at a weird angle, etc, (I believe being off-grid may contribute too but IIRC it can happen even on grid if there's still a sliver, and IIRC the sliver may even be buried in the brushwork?) and cleaning up the brushwork into simple, blocky & flush brushwork fixed it for me.

 

The catch is the problem line is where the blackness/invisibility starts, that is actually off on the far side, not in the center of it, so it's tricky to catch. So first look around where the blackness starts/ends for any suspect tricky brushwork & simplify it into something flush. That was my solution that always worked anyway. I think it has to do with the renderer burping on the sliver brushwork and it kills any brush from that point forwards.

[Lux]

Well, I'll try just selecting everything within range and snapping it to the grid and see what that does. I guess it would take less time to recheck the whole building for internal leaks then keep chasing down new gaps. Very frustrating.

 

I've had some monsterous issues doing this. Reason being which I'm sure you're aware of was that when you group select a bunch of items and then snap to grid, if the vertecies are past the median to the next point, they snap to the wrong grid point there by opening the gap further. Depends of course on your grid setting at the time of the snap. Can be very frustrating.

[Airship Ballet]

Oh for christsake. I deleted the visportal on the main map, snapped everything to the grid--exactly what solved it in the tesmap--loaded the map up and the same problem is still there, along with the entire side of the building being see-thru.

 

I've had this. I've just been turning cloning them, turning one to func_static and the other to worldspawn, then putting the latter just inside the former to seal the geometry. That way it doesn't matter if the worldspawn vanishes because afaik it still functions to seal out the void. There's no real tri cost since it isn't happening all over the place. It's a messy solution but it doesn't look any different when you're playing.

[Springheel]

I've never seen this dmap error before...does this mean anything to anyone?

 

"primitive 1024 has more than 128 wingdings"

[RJFerret]

I've never seen this dmap error before...does this mean anything to anyone?

 

"primitive 1024 has more than 128 wingdings"

 

Google searching it turns up a reference from a few years ago, someone by the name of "Springheel" had that error, but the thread doesn't make it clear what the resolution was: http://forums.thedar...gs-during-dmap/

 

He'd never seen it before either. ;-)

 

I've had this. I've just been turning cloning them, turning one to func_static and the other to worldspawn, then putting the latter just inside the former to seal the geometry. That way it doesn't matter if the worldspawn vanishes because afaik it still functions to seal out the void. There's no real tri cost since it isn't happening all over the place. It's a messy solution but it doesn't look any different when you're playing.

 

Showing the void, yet obscuring it with a cosmetic mask doesn't sound like sealing the void to me, but I don't know the technical treatment of it. However not fixing it defeats the rendering system from not rendering proper sections for performance, and may prevent the location system from working (since the leaf overlaps), so incorrect ambients, AI pathing issues, and sounds coming straight through instead of propagating as expected.

Edited February 3, 2014 by RJFerret

[SteveL]

EDIT: Please wait for an update in another thread before trying this script (unless you want to help debug it:) ) We have arithmetic weirdness to deal with.

 

It strikes me that finding off-grid worldspawn and slivers and the like is an ideal job for DR's scripting capabilities. Using a script to find problem brushes would mean you can treat them individually, either correcting them or converting them to FS, without having to snap everything to grid and then go looking for leaks.

 

Unlike the PatchSplitter script I did last month, this one can be completely menu-driven. I've spent the last hour doing a proof of concept script that does one thing: it selects all off-grid worldspawn brushes in your map, after popping up a box where you can choose the grid size to use. If people think it's a good idea, it can be extended to include options to find slivers, overlapping brushes, duplicate brushes, distant faces aligned with VPs, etc.

 

I'll paste it here (hope you don't mind Springheel) since lots of experienced people who have been thinking about the topic are already gathered in one thread And it might help you find the irregularities in your map.

 

grid_check.py.txt

 

What it does

Pops up a box asking you to choose a grid size, then clears your current selection and selects any worldspawn brushes that are off-grid at that scale. It ignores brushes that are part of an FS.

 

How to install

Save the attached .py file to Darkradiant/scripts/commands, where Darkradiant is your install folder. Remove the .txt extension as usual. For Windows users the default path is:

C:\Program Files\DarkRadiant\scripts\commands

 

Then restart DR.

 

How to use

Under DR's Script menu, you'll find a new option: Select off-grid worldspawn brushes

 

Quirks

The script has no way to tell whether a given brush is currently hidden or not, so if you have part of your map hidden, it'll get checked and some brushes might be selected anyway. You might see the origin of the selection floating off to the side, because of distant hidden brushes that are selected. Shouldn't be a problem if you fix the brushes by selecting vertices, but probably best to use it to find the brushes, then clear and re-select before converting one to a FS or dragging it.

Edited February 3, 2014 by SteveL

[Springheel]

loaded the map up and the same problem is still there, along with the entire side of the building being see-thru.

 

Good news: the black wall is gone now...There was a remaining support beam that had a corner clipping into the sloped ceiling. When I converted it to func_static, that problem went away.

 

Bad news: The new problem that started happening, of half the outside wall being see-thru, has not yet gone away. I've been converting things and adjusting brushes all morning with no luck. When I copy just the brushwork to another map, the problem doesn't occur, which has me (once again) perplexed. Is it possible for this problem to be caused by func_statics or models?? I thought only worldspawn needed to be considered.