Please report crashing maps and renderer glitches

[Springheel]

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.

 

Sure. I don't think anyone is suggesting, or has ever suggested, that having seven overlapping lights is a good idea.

 

However, Merry said she was told not to use the method of turning brush walls into func_static, and you suggested there was a good reason not to do that. I'm still trying to understand what that reason is. Performance obviously is not an issue when you're dealing with regular rectangular wall brushes.

[nbohr1more]

You "can" turn walls into FS as long as "something" is sealing the void, whether it be caulk or some other opaque worldspawn outside the wall.

FS doesn't seal so you if you don't surround a room with something that does the engine will treat the walls as transparent.

 

It would be damned cool if you could have "sealing" FS, not sure if that's feasible with the whole dmap structure though.

[SteveL]

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.

This *is* wrong. Func_statics have *no* effect on visportals opening or closing. Only opaque worldspawn, the VPs themselves, and deliberate switches like doors and func_portals matter.

 

To pick up on some of the other points:

Models -- including FS surfaces -- don't re-upload anything to the gpu unless either the light or the surface moves. If the light moves, the indexes (the list of which tris in the model are hit by the light) get re-calculated and re-uploaded. If the model moves but remains rigid -- like a func_rotator or a func_mover -- then again those indexes get re-done. The only time the verts will get reuploaded is if the surface deforms -- like AI's skin and particles do.

 

If your light and your FS are both static, nothing gets uploaded to the GPU each frame. It's just a draw call for each texture used in the FS. And light boundaries are still important -- unless the light covers the whole screen view. Screen-aligned rectangles are used to stop unnecessary parts of the model being drawn. That doesn't help for a light that covers the whole sceen, but if a light covers only the bottom left of the screen for example, the only part of any FS lit by that light to get drawn will be the bit that overlaps the smallest screen rectangle covered by that can contain the light volume as seen on screen. The only time the extra tris come into play is if the model or the light moves.

Edited January 19, 2015 by SteveL

[nbohr1more]

Hmm. Since all torches are moving lights, I wonder if there'd be a substantial saving to move the light_center rather than the light volume itself.

[SteveL]

Hmm. Since all torches are moving lights, I wonder if there'd be a substantial saving to move the light_center rather than the light volume itself.

Unfortunately not: changing either of those things will invalidate the lists of lit tris. As will changing its axis, any of its frustum planes, its radius, shadowcasting status, parallel / spot / directional settings, target, shader or prelightModel.

 

Yes, I cheated and got that from the check in idRenderWorldLocal::UpdateLightDef

 

Most torches are not moving lights by the way. They used to be I believe, but I think the default effect nowadays is to make them flicker by changing the light intensity and/or fiddling with the material translate setting in some way, not by changing the light position.

[nbohr1more]

Yeah, I thought it was a long shot. I recalled GoliathVT over at Doom3world solved his "sun moving across the sky" problem by moving the light_center

but that's a special scenario where a VERY large light volume would've needed to traverse a very large scene.

[Springheel]

You "can" turn walls into FS as long as "something" is sealing the void, whether it be caulk or some other opaque worldspawn outside the wall.

 

Maybe we were talking past each other. No one was suggesting not having any sealing worldspawn. My suggestion to the OP issue was to make a wall func_static, but put a thinner brush inside it (rather than snapping to a .125 grid). That thinner brush is for sealing purposes. Merry said she was warned not to do that. I'm curious about who warned her not to do it, and whether they actually had a good reason for it.

[nbohr1more]

Yeah, I don't recall handing out that suggestion. I can only say that it's more practical for flat walls to be WS most of the time.

[Airship Ballet]

http://forums.thedarkmod.com/topic/16093-disappearing-worldspawn/?p=340778 and onwards. Some other advice I'm glad I didn't follow, too

Edited January 20, 2015 by Airship Ballet

[Springheel]

I didn't get the sense that they were arguing that you shouldn't build a plain brush wall for sealing and then func_statics for visuals...it seemed to me more like they were talking about brushes being grid-snapped.

 

The optimal way to build, I've come to believe, is to build a bare shell map out of brushwork--all grid aligned, blocky and without any decoration whatsoever. These brushes are there just to allow you to seal visleafs--the player will never see them. Then, you add func_static or model facades over top of the brushwork. The func statics are where you worry about the visuals, and since they're not sealing anything, you don't have to worry about grid-aligning, you don't have to worry about gaps or slivers or intersecting or anything else beyond how it looks. And if you keep your sealing geometry on another layer, you don't even have to worry about accidently opening internal leaks.

[Airship Ballet]

There was certainly a lot of that, but I did get told that worldspawn to seal with a func_static surrounding it wasn't ideal and when I got it off RJ it had been removed too. The worldspawn was snapped to the grid, just that the sealing geometry was maybe 4 or so thick rather than 8. It was some of the smaller parts in a bar I built that were off-grid after being worked on, as well as some wall trims. They were the cause of things disappearing in the end. The general sense I get is that the more tiny, complicated func_static objects you make with patches, the more likely you are to get things not rendering, sometimes even once it's all completely on-grid. There's definitely correlation, if not causation.

[Springheel]

The general sense I get is that the more tiny, complicated func_static objects you make with patches, the more likely you are to get things not rendering,

 

 

My understanding is that func_static objects cannot create rendering problems...only brushes or patches that aren't converted can. Can anyone clear that up?

[Airship Ballet]

Well, I meant more the process of making them. The smaller and more fiddly the patches, the more graphical bugs and disappearing brushes I see. Like I said, correlation if not causation as I've no idea how the renderer works.

[SteveL]

I can add a bit of theory based on what I've read in the code, though I'll bow to experience

Func statics definitely shouldn't be involved in any of major dmapping problems: visportals not working properly, internal or external leaks, worldspawn surfaces not being rendered, player origin getting into the void. That's because those things -- the 3d space of your map (i.e. the bsp), the portals, and the visible models generated from worldspawn -- are all completed by dmap before it even looks at your func statics.

There's one minor exception to that rule: dmap works out which bits of your map are accessible, i.e. non solid, by tracing out from each entity origin until it hits a solid surface. So func statics *can* influence which bits of the map are considered "accessible space" as opposed to solid wall or void, but they do that the same way any entity does, and only the origin matters, not the complexity of the model.

Complex func statics made of brushes and patches might well be able to cause rendering glitches within themselves. Once your worldspawn has been processed, dmap moves on to your func statics and it treats each one in turn like a little map in it's own right, turning the brushes and patches into a set of visible models and then retriangulating and optimising those surfaces, removing hidden inner surfaces etc. It uses the same procedures to do that that it used to do the same thing for your worldspawn. The only difference is there are no visportals, and it doesn't have to decide which bits are part of the map and which bits are void. But it might be able to mess up a complex FS occasionally. The damage would be confined to that FS though, it shouldn't mess up anything else, or affect how the map works.

 

As for the renderer, all that's left of your FS by the time you load the map is a set of non solid model surfaces, like you'd get from any model, and a separate clipmodel that makes it solid. Nothing that should be capable of interfering with a visportal.

[Tels]

Maybe we were talking past each other. No one was suggesting not having any sealing worldspawn. My suggestion to the OP issue was to make a wall func_static, but put a thinner brush inside it (rather than snapping to a .125 grid). That thinner brush is for sealing purposes. Merry said she was warned not to do that. I'm curious about who warned her not to do it, and whether they actually had a good reason for it.

 

If a large triangle (like a wall side) is hit with two lights, the entire triangle is rendered twice, for each light. If two smaller triangles representing the same wall are hit by one light each, the wall is rendered only once.

 

This is a fill-rate issue - rendering large batches of pixels twice can incure a hefty performance penalty, esp. if shaders are involved, like post-processing, or anti-aliasing.

 

So if you turn a worldspawn wall into an FS, the wall might suddenly not anymore be split up (WS is split up at other WS brushes, FS are not). You save on triangles (slightly), but loose big on fillrate.

 

It depends on the hardware and the situation, of course.

 

There is also the issue that a func-static crossing a portal might have ill side-effects, for instance the engine needs to determine in which area the FS is, but if its crossing the boundary, this can lead to errors that cost performance. Not sure how relevant that is, however.

[SteveL]

Tels, this isn't aimed at your post, it applies to many posts that give confusing advice to mappers. Often, some of the advice applies to our engine, some of it to other engines, some of it to none. TDM engine has its own set of optimisations (and they are good ones), many of which take these matters out of the mapper's hands, so mappers should not be worrying about them. Advice that's too generalised can create people a lot of work and worry that ends up having no effect on performance.

 

When people say that something -- let's call it 'X' -- is "rendered" in TDM they might mean any of these things:

1. X is checked to see whether the player can possibly see it.
2. X's shadow is roughly estimated from each light to see whether the player might be able to see its shadow.
3. If X is an animated entity like an AI or a flag, its skeleton and skin and clothing positions are worked out.
4. X's vertex coordinates and/or list of lit triangles and/or shadow-casting silhouette is uploaded to the GPU.
5. X is tested to see how much of could show up on the screen, and triangles are discarded it they face the wrong way. (that is, X is clipped, and culled).
6. X is rasterized, that is, the gpu works out what screen pixels it would cover if it got drawn.
7. X's pixels are tested to find out whether they can be seen or are hidden, in one of various ways (and TDM engine uses them all). I mean tested against:
   • the screen-coverage rectangles of the current draw call (scissor test)
   • the depth bounds of the current draw call (depth bounds test)
   • the rest of the scene geometry (depth test)
   • the per-pixel stencil for the current light, taking into account shadows (stencil test)
8. X is shaded, i.e. its pixels are coloured in, taking into account lights and diffuse map and normal map and specular map.

Triangles and groups of triangles (=surfaces) can drop out of the process at stages 1, 2, 5, and 7 (any of the 4 sub-stages) in that chain so whether or not something is "rendered" isn't a yes/no question.

 

When you talk about "fill rate", that covers stages 6-8 in the list so again, whether a given tri contributes to fill rate is not a yes/no question. It's how much it contributes that matters. Parts of an FS that can't be seen will drop out somewhere during step 7, and step 8 is the expensive part where func statics are concerned. Step 6 is most important for shadows in complex scenes. You can see from that list that the engine is perfectly capable of rendering a bit of a triangle for a given light.

____

 

Rant over, on to the specific topic of FS vs worldspawn.

 

My advice is, it's not an important thing that mappers should be worrying about. In nearly all cases, a wall will be rendered just the same whether it's an FS or worldspawn. Your advice about crossing portals is worth noting for huge FS, but doesn't really apply to the case we are talking about. Yes it would probably be bad to make the entire floor of your mansion or outdoor area a single FS patch, because the entire 20000-unit-wide surface would make it quite far down the rendering process outlined above, but that's not what we're talking about here. We're talking about using 128-unit wide modular walls so that maps can be made much more beautiful and in much less time, and without any performance penalties.

[Springheel]

so mappers should not be worrying about them. Advice that's too generalised can create people a lot of work and worry that ends up having no effect on performance.

 

 

I can't +1 this enough.

[Tels]

I wasn't actually arguing against or for converting WS to FS, sorry if that did come out wrong.

 

What I was talking specifically about the case of "one wall is divided into multiple triangles by a visportal intersecting it" vs. "the same wall is a func_static that is not divided" and in both cases the entire wall is on the screen, AND it is hit by two more more lights on different ends (like say two torches on colums at either end, or one light on the wall and one in the player hand).

 

Specific optimizations like "you look the other way and the wall is not rendered" nonwithstanding, in THAT case (you see the entire wall, X lights are hitting it), either only parts of the wall are rendered once or a few times, vs.r the entire wall is rendered multiple times. That can definitely make a difference in fillrate, esp. on older hardware.

 

This is of course not a black-white question, but as a mapper you should optimize your level so that the triangles are not overly huge (huge fillrate penalty if same triangle is hit by multiple lights), NOR should they be overly small (performance penalty on processing too many small triangles).

 

So the general advice is: Make sure the triangles are distributed evenly in a scene, (use r_showtris 1) and test your level on older hardware. And do this as the last step of mapping. Deviations from that rule are of course ok.

 

The general "mappers should not worry about it" I cannot underwrite - unless they don't care about performance at all. In all other cases, mappers should pay attention - but only later, and not in the first stages of level build. And of course not worry too much - you are right that in a lot of cases the performance will not change because the hardware has become quite powerful nowadays, and a few thousand triangles more or less, or a few mbyte pixels shaded more or less make almost no difference.

 

My advice is, it's not an important thing that mappers should be worrying about. In nearly all cases, a wall will be rendered just the same whether it's an FS or worldspawn.

[Tels]

As for the renderer, all that's left of your FS by the time you load the map is a set of non solid model surfaces, like you'd get from any model, and a separate clipmodel that makes it solid. Nothing that should be capable of interfering with a visportal.

 

The engine decies in which area each FS is - if the FS crosses into two areas, the engine will have difficulties culling it. And by "interfering" I also meant that a visportal will not cause a FS faces to be split at the portal - faces will stay whole. (can make a difference in specific cases).

 

Plus I dimly remember a bug that screwed AI pathfinding when a FS intersects a portal (I think Fidcal wrote about it).

 

You are right, all of these might not matter in a lot of cases, but it can happen. So mappers should be at least aware of what they are doing.

[nbohr1more]

This whole discussion reminds me of beta testing ERH+'s mission "Crystal Grave".

 

There was a small room at the far end of an interior courtyard that had HORRIBLE performance (4 to 5 FPS).

When I did an r_showTris 2 I saw one of the Tree models from outside the room was rendering.

I nudged the model a little farther away from the room and then tested again (r_showTris 2) and it

was no longer visible and performance went up to 25FPS. Not too shabby. So if a func_static is sufficiently

complex and it crosses a worldspawn or portal boundary it can drag down performance for sure. Most

likely because that small room had at least a few interesting mood lights and some light radii from outside the

room also overlapped into it. It would be cool to see exactly how that scenario plays out in relation to

the above render outline steps but the fix was simple at least... keep complex FS from crossing leafs.

[SteveL]

It would be cool to see exactly how that scenario plays out in relation to

the above render outline steps but the fix was simple at least... keep complex FS from crossing leafs.

I'd be interested in knowing what happened there too. I don't doubt the accuracy of your observations at all, but that's only one data point and it hasn't been investigated. I'd hesitate to infer a rule from it, especially one that imposes heavy restrictions on map design, and when the theory suggests that there must have been some other effect in play.

[Springheel]

I saw one of the Tree models from outside the room was rendering.

I nudged the model a little farther away from the room and then tested again (r_showTris 2) and it

was no longer visible and performance went up to 25FPS

 

 

One of our tree models? I highly doubt a single tree model could cause a drop from 25 to 4 fps unless something unusual was going on. A static tree has far less of an impact on performance than a single AI.

[nbohr1more]

 

One of our tree models? I highly doubt a single tree model could cause a drop from 25 to 4 fps unless something unusual was going on. A static tree has far less of an impact on performance than a single AI.

 

Yes, I'll see if I can find the old version of the map. Basically I think a leaf plane was poking into the room thus the whole model was getting lit by all the lights that the small

plane was hit by. I'll put a tree in small room and shine 5 lights on it to compare.

 

Such a small room shouldn't have 25fps either but the light count was higher than the norm as I recall.

 

This was when I had my HD4650AGP and P4 3.0GHz. I am sure even the old map would perform better on my current hardware.

[Springheel]

Basically I think a leaf plane was poking into the room thus the whole model was getting lit by all the lights that the small plane was hit by.

 

Even so. Unless it was getting hit by four or five moving lights all at once, I can't imagine how it could result in that kind of a fps hit. A single AI has at least three or four times the number of polys, all of which are animated and therefore require more calculations than a static model, yet a single AI doesn't cause that kind of problem, even with all the pathfinding and other calculations that come along with it.

[nbohr1more]

No doubt that there was probably still some bizarre edge case there.

 

Hmm...

 

Trees have a more complex winding structure. If you are trying determine a silhouette the are about the worst thing to work on.

The only thing close on an AI are the arm \ hand \ finger structures.

 

The silhouette determination is probably out of the window though since (as I recall) it was set to noShadows...

 

I'm wondering if the AAS was trying to parse the inside of the model or something...