Please report crashing maps and renderer glitches

[SteveL]

An appeal to mappers: If you're working on a map that crashes the game for no apparent reason, or if bits of your map don't get drawn on screen, or if you get glitches around visportals, please report it and/or PM me or grayman a copy of your work-in-progress. No need to tidy it up or resolve other issues.

 

Crashes are very easy to diagnose in a special debugging version of the engine, and they're often easy to fix permanently in future releases. Reproducible renderer glitches are very useful for improving the renderer and dmap. If you fix them by tweaking the map instead of reporting them, we don't get a chance to fix the root cause.

 

(Plus it might save you days of frustration struggling with a glitching map).

[Bikerdude]

You might want to drop Melan a PM as his TDM install is crashing for some reason, and I might be related.

[SteveL]

Is that the same problem we already looked at, where you and I can run the map ok but it crashes for Melan? If so it's not a map/TDM issue, Melan can probably fix it by deleting and re-downloading TDM.

[Bikerdude]

Is that the same problem we already looked at, Melan can probably fix it by deleting and re-downloading TDM.

Yes, and he has already done that. Its just crashing less now.

[SteveL]

Yes, and he has already done that. Its just crashing less now.

That's a toughie. If I can't reproduce the crash, I can't diagnose it. On the other hand, if the map crashes for him with a fresh download of TDM, then maybe I can rep it, maybe I just didn't step into the same area of the map or do the right thing to make it crash.

 

@Melan, do you know of a reliable way to make the map crash?

[Agent Jones]

Hello. I've noticed that my brushes look like they have cracks in-game, even though they are perfectly aligned in the editor.

 

A couple of triangles have disappeared here. The only way I've found to fix this bug is to move this big triangular roof brush away,. This is not new to me (it happened with the Q3 editor a long time ago), i just wanted to let you know.

 

My game crashed a couple of times while AI was chasing me, but it happens so rarely that i've never been able to reproduce the bug.

 

On a possibly unrelated note, while my brother was working on a small test map in DR, all his models were shifted by a certain offset in the 2d view, and the same happened in the 3d view for both models and worldspawn. The graphical representation and the actual object did not match. I'll never know what caused this because he has deleted the file, but I'd like to know if anyone has ever experienced the same issue.

Edited January 18, 2015 by Agent Jones

[Bikerdude]

This might be the hair-line brush edge & caulk issue, where a hidden suface has a caulk texture and the user/player is seeing sparklies in-game...?

[Agent Jones]

This might be the hair-line brush edge & caulk issue, where a hidden suface has a caulk texture and the user/player is seeing sparklies in-game...?

I've tried texturing all the caulk surfaces and the problem persists

[Bikerdude]

I've tried texturing all the caulk surfaces and the problem persists

You ms-understand, the issue Im refering too is when a hidden surface has a caulk texture meets the 'join' where that surface meets the perpendicular edge of a normally textured surface you sometimes see as we call them "sparkles".

[VanishedOne]

When I've had mysterious vanishing surfaces, selecting the entire map, selecting the smallest grid size and doing 'Align to grid' has sometimes fixed it.

 

Last night I had sparkles on brush surfaces adjacent to some moderately complex patches; r_showTris 1 showed that dmap had got a bit carried away in subdividing the brushes to match the patches' verts. The solution was to convert the brushes to a func_static.

 

I don't know whether either of those will help in this case, though.

Edited January 18, 2015 by VanishedOne

[SteveL]

Glitch.jpg

Hello. I've noticed that my brushes look like they have cracks in-game, even though they are perfectly aligned in the editor.

Hairline fractures like that are not so much bugs as design consequences. You grid-snap your verts in DR but game engines including ours often treat brushes as sets of planes offset from the origin and the two don't always line up perfectly. As Biker says, you can sometimes cure it by texturing the hidden surfaces, but you aleady tried that. Assuming the brushes are already flush, sometimes the only way to fix it is to tweak something or cover it up.

 

glitch3.jpg

A couple of triangles have disappeared here. The only way I've found to fix this bug is to move this big triangular roof brush away,. This is not new to me (it happened with the Q3 editor a long time ago), i just wanted to let you know.

That could be another example of a dmap problem that I diagnosed in the summer but haven't thought how to fix yet. I'd be happy to take a look at it when 2.03 is released. Are there any slivers in your map? A sliver is a piece of worldspawn 0.1 units or less thick, i.e. a bit smaller than min grid size. It can cause dmap to delete parts of your worldspawn. A tell-tale sign is if you stand in the missing area, do all visportals open?

 

On a possibly unrelated note, while my brother was working on a small test map in DR, all his models were shifted by a certain offset in the 2d view, and the same happened in the 3d view for both models and worldspawn. The graphical representation and the actual object did not match. I'll never know what caused this because he has deleted the file, but I'd like to know if anyone has ever experienced the same issue.

I've never heard of that happening before.

 

When I've had mysterious vanishing surfaces, selecting the entire map, selecting the smallest grid size and doing 'Align to grid' has sometimes fixed it.

You're not the only one... Merry (Airship) has found this tactic helpful too. But I'd class it as a very high-risk tactic and I'd say anyone who wants to try it should check out their map and visportals thoroughly afterwards before doing more work on it. If all your sealing geometry is square-cornered, it might be ok. But if you have any clipped walls (think sloping attics, angled doors) where the verts are likely to be already a bit off-grid, then it could easily open up small internal leaks.

[grayman]

When I've had mysterious vanishing surfaces, selecting the entire map, selecting the smallest grid size and doing 'Align to grid' has sometimes fixed it.

 

 

Not recommended.

 

There are plenty of vertices, especially in a large map, that shouldn't be "on grid" and forcing them to be so is going to screw up your architecture.

 

It's best to fix the problem locally and not globally.

[Agent Jones]

Thanks to everyone for their dedication.

 

When I've had mysterious vanishing surfaces, selecting the entire map, selecting the smallest grid size and doing 'Align to grid' has sometimes fixed it.

Last night I had sparkles on brush surfaces adjacent to some moderately complex patches; r_showTris 1 showed that dmap had got a bit carried away in subdividing the brushes to match the patches' verts. The solution was to convert the brushes to a func_static.

I don't know whether either of those will help in this case, though.

Aligning everything to the smallest grid made the crack less noticeable,but it was still there. The only solution was converting the brushes to func_static,and i said goodbye to that portal. If I covered the func_static with caulk, would that fix it?

That could be another example of a dmap problem that I diagnosed in the summer but haven't thought how to fix yet. I'd be happy to take a look at it when 2.03 is released. Are there any slivers in your map? A sliver is a piece of worldspawn 0.1 units or less thick, i.e. a bit smaller than min grid size. It can cause dmap to delete parts of your worldspawn. A tell-tale sign is if you stand in the missing area, do all visportals open?

There are no slivers in my map and the visportals are fine. That's puzzling.

 

 

 

[Springheel]

Aligning everything to the smallest grid made the crack less noticeable,but it was still there. The only solution was converting the brushes to func_static,and i said goodbye to that portal. If I covered the func_static with caulk, would that fix it?

 

 

You can always put a smaller brush inside the offending (now) func_static to seal things. I had to do that in my map because there was an entire wall that kept disappearing. I just made it a func_static and put a thinner wall inside it, and problem solved.

[Airship Ballet]

I just made it a func_static and put a thinner wall inside it, and problem solved.

I got told off for doing that! I'd done it everywhere but apparently it would cause huge problems, so I snapped everything in the area to the grid and it was fixed. Do so in the area where brushes are disappearing, and (as has been said) check everything around it afterwards or hide everything you don't want snapped beforehand. I've found it also helps to fiddle around with what you've built. If it's not sealing, try turning it back to worldspawn or making it func_static if it is already. As far as I know, the requirements for something to disappear like that are very slim, so typically moving things around a bit, changing which parts are statics and which are worldspawn and just generally toying with it will fix it with little to no change. If all else fails, rebuild it and you'll usually find it's fine.

Edited January 19, 2015 by Airship Ballet

[SteveL]

There are no slivers in my map and the visportals are fine. That's puzzling.

 

That's intriguing. A fresh bug to work on! If you have a copy of the glitching work-in-progress, please PM it although I won't get to look at it until after 2.03 is out.

[SteveL]

I got told off for doing that! I'd done it everywhere but apparently it would cause huge problems

 

That's actually the direction we want to go in (using FS or models for visible walls and having thinner invisible/caulk walls within them to separate visleafs), so if you do find a problem with the approach I'm up for spending time diagnosing it. From what I've seen and heard, it's already one of the least problematic ways to map, so there are probably mixed messages around.

[nbohr1more]

Yeah, the only reason to get "told off" for using that approach is that func_statics don't divide on light boundaries nor do they split

at portals. So you either need carefully ensure that you have "some" worldspawn where it's needed to perform these actions.

That's why I mentioned that caulk "can" improve performance. A world-spawn free map will perform terribly indeed.

[SteveL]

Yeah, the only reason to get "told off" for using that approach is that func_statics don't divide on light boundaries nor do they split

at portals. So you either need carefully ensure that you have "some" worldspawn where it's needed to perform these actions.

That's why I mentioned that caulk "can" improve performance. A world-spawn free map will perform terribly indeed.

??? No-ones suggesting you make the whole map a single func_static. Keep them room-sized or less. Can you think of any spots where a mapper needs to use visible worldspawn? (as opposed to places where it's just easier and has no perf consequence one way or the other, like flat floors between rooms on different levels of a building).

[nbohr1more]

Visible worldspawn is not needed per se but if you do not expose worldspawn you must split your func_statics at those boundaries or ensure

they are small enough that any rendering boundary problems would incur a minimal performance impact. Yes, func_statics typically win but

in scenes with more lights they can cause problems. Of course, if the per-light rendering penalty is reduced in v2.04 this may be obsolete thinking....

[nbohr1more]

I guess the one unclear thing here is how func_statics can contribute to delayed portal closure. As I understand it, the visibility code only closes

the second portal away from the player that is behind the first obstructed portal but only does so if nothing in that first obscured visleaf is visible

to the user. If a func_static crosses the first visportal boundary then the engine counts the whole leaf as visible then treats the second visportal

as the demarcation point and finally closes the third portal away. Please correct me if I'm wrong here.

[Springheel]

 

Yeah, the only reason to get "told off" for using that approach is that func_statics don't divide on light boundaries nor do they split

at portals.

 

 

And why is that a problem?

[nbohr1more]

 

And why is that a problem?

 

If you don't divide at the light boundary, the object will re-render in it's entirety for each light that hits any part of it.

Each light rendering pass is the most expensive thing the engine does.

 

Each light must:

 

1) transform vertices to triangles on the CPU (skinning)

2) Determine shadow silhouettes on the CPU

3) determine visible polys and set flags in the interaction table

4) pass the skinned triangles over the AGP\PCIE bus

5) mask out shadow pixels for every poly the light touches (visible or not)

6) run the entire interaction shader for every poly the light touches that is within the interaction table

 

With this engine you are always weighing poly count vs light count and the way to get an edge is to ensure that

you aren't wasting light count polys on un-needed overlaps.

 

You can actually have a great number of lights per scene as long as they don't overlap. I think Treb saw one vanilla Doom 3

map that had over 50.

[Springheel]

If you don't divide at the light boundary, the object will re-render in it's entirety for each light that hits any part of it.

Each light rendering pass is the most expensive thing the engine does.

 

 

Ok, so worst case scenario is that there might a performance hit? In the case we're talking about, turning a brush into a func_static and putting a thinner brush inside, how many polys are we actually dealing with? Twenty? A hundred?

 

I have a hard time believing this could have any perceivable performance impact.

[nbohr1more]

If you have a large detailed func_static with about 2000 polys and it is hit by 7 lights, that's 14,000 polys to be processed on the CPU.

(plus all the shadow silhouette polys)

 

That's why the rule of thumb has generally been to keep overlaps to under 4 lights if possible. It all depends on the complexity of the object

but mappers often feel at ease to create very complex objects with FS because they know that FS generates far fewer polys than

the equivalent brush geometry. Still, brushes aren't perfect at splitting at light boundaries either so you can have pretty much negligible

performance gain from reverting to worldspawn unless you use "brush carving" techniques to force the splits.

 

Moobo recently had good results with revert to WS without brush carving in a scene with many lights.

 

http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/page-242?do=findComment&comment=362623