Backface cull performance?

[obsidian]

By default, game engines will cull polygons with normals pointed away from the PoV. Is there any performance benefit to manually deleting sides of a mesh that won't be seen by the player? For example, I have this model that is sitting in a place where the player will only ever be able to see one side of. The faces on the other side of the model will be culled from drawing on screen. Is there any point to manually deleting the unseen faces if the game engine will cull them for me?

[Noruen]

Engine automatically do not show these faces/polygons - tested. Or you really need to cut them off manually? I think there is no other way than model editing. I have tried to surround the unseeable part of model by brush with clip, but it doesn't worked. Anyway, engine do it automatically.

[o'dium]

Every surface I make is caulked/skipped/whatever except for the visible side. Reason being is that the compiler will ignore these surfaces 100% and just won't even compile them into the BSP, making compile times shorter.

Also, just because you can't see something, it doesn't mean its not being drawn, for example a wall behind another wall, and that will still impact fillrate.

[obsidian]

Also, just because you can't see something, it doesn't mean its not being drawn, for example a wall behind another wall, and that will still impact fillrate.

That's PVS surface culling, in which case walls in the next room might be drawn if you didn't hint them properly. Backface culled polygons are the sides of a wall that are not facing you and they are actually NOT drawn, the engine automatically removes them until you walk around to the other side. I'm wondering if there is any other performance impacts, I suppose the surfaces are still loaded into memory. Assume: no lightmap, no extra textures, detail.

In my situation, I have a model in one part of the map and the player can only see the front. In another part of the map, the player can only see the back of the model. I could just place the same model in both places and let the engine cull the opposite sides. Otherwise, I'll have to manually delete faces and create 2 separate models for front-only and back-only views. I'm guessing that the first method would work fine, but maybe I'm missing something.

[Noruen]

Well, so you don't want faces to be drawn, or even loaded into memory?

I know, you know it, but try "r_showtris 1" in game, and see if that faces are drawn or not from your wanted position.

But I think, from the view of performance with size of models in Q3a in mind, that there will be no rapid influence on performance (I'm a poet). If you use two models = same as use one model.

Just say, you need to improove performance, or is it only theoretical question?

[o'dium]

Also, just because you can't see something, it doesn't mean its not being drawn, for example a wall behind another wall, and that will still impact fillrate.

That's PVS surface culling...

I know what that is, mate But thats not always an option. For example, a player model stood in front of a wall still draws the wall behind him, even in the areas the player covers. Thats a bit of a wild example, but it works with walls too... Just because you can't see something doesn't mean its not going to be drawn, even with decent hinting and PVS tweaks.

Backfaced polygons are NEVER drawn... I never said otherwise. The only time they are drawn is when you tell the engine to draw them (twoSided, for example).

Your last example, model surfaces dont work like that, there is no culling in that case, not like you understand with levels. I honestly wouldn't worry about drawing the model front and back, it cant be THAT complex that it makes Q3 run slow... And if it is, then you really have a piss poor pc. And I'm not saying that to be mean, I'm saying that because if your PC lags with something that simple, then chances are making ANOTHER model to load into memory that has different pre-culled faces will impact memory in a way that will also be a performance drain... So you have to ask yourself which is worth it?

Noruen: r_showTris 1 will only load the tris that can be seen from the current location and wont render the wireframe behind objects. You are much better off using 2 or 3 so that everything thats being rendered at the current moment is shown instead.

[^misantropia^]

How many vertexes / faces are we talking about here? Backface culling is a fairly cheap operation but if you have hundreds or thousands of unseen faces, you should remove them.

[Noruen]

O'dium - I thought, that when I use r_showtris, everything what IS rendered is rendered. So if i DO NOT see faces, it means that face is not rendered. And I think that's what Obsidian was talking about - if the engine is able to "remove" not-visible faces from current rendering process, or i must be done manually.

[o'dium]

O'dium - I thought, that when I use r_showtris, everything what IS rendered is rendered. So if i DO NOT see faces, it means that face is not rendered. And I think that's what Obsidian was talking about - if the engine is able to "remove" not-visible faces from current rendering process, or i must be done manually.

r_showTris 1 (If I remember right, I don't use Q3 anymore) will just draw a wireframe of the current geo thats drawn. It wont even draw the wireframe of the polygons behind the players weapon, for example. 2 and 3 are expanded.

[Noruen]

Yes, it shows. And thats the punchline. I want to know what is drawn right now. It shows everything what is rendered. If it is not visible on this wireframe, it is not rendered. But I can be wrong.

[dONKEY]

I thought entire meshes got loaded into memory. I've never read any studies on how performance is affected. Logic would seem to dictate the more complex the mesh the more memory required thus the bigger the hit on performance. I kind of ran into this with my noghost map. I modelled all the geometric elements so I could use and reuse geometry, using the editor a bit like a Lego set. This meant as models were going to be rotated differently in different locations, quite often I had sides of a mesh buried from view. My feeling is that unlike unreal, this approach in q3 does cause issues in complex maps.

[stevec]

I imagine that removing the faces would result in less memory on vertex position/triangle lists and as a result less data being processed by the back-face culling system. I'm not sure how much of an impact this would have on a low-medium detail model but for something where thousands of faces might not be visible the results could be somewhat more pronounced.

This all also depends on the engine, as I think that the majority of engines now only retain a single copy of the model data in memory and having multiple variations of the same model with certain faces removed might just end up being a waste of memory with very little (if any, it could perhaps even hinder) gains in rendering speed.

[obsidian]

The entire model is sitting at around 3600 tris. Some optimization, I should be able to get it down to around 3200. Removing the backside, I might be able to get it down to about 2000, but this would require a lot of work since it's not exactly apparent what is on the backside and what isn't.

Hello, stevec. Welcome and thanks for joining in. Yes, most new games have model instancing. Quake 3 isn't so smart.

I guess I'll have to do a bit of experimentation.

[fKd]

interesting stuff! screenshots or it did not happen obs, and where are those texture sets? heh

also, welcome stevec

[^misantropia^]

Obs, simple test. Set com_maxfps to 1000 or so and check the frame rate when viewing the model. Then recompile with the model chopped in half and check the frame rate again. Optimize your model if there is a big change in FPS, otherwise don't bother.

[Eraser]

Does culling like this apply on both geometry and models? Aren't models handled separately from geometry?

[^misantropia^]

Yes and yes.

[jal_]

There are many different things involving this case. For a start, it's 2 different worlds if you are forcemetaing the model or not, or if it's structural brushes or detail brushes. If it's structural brushes then basically you can ignore it, because those faces will be removed in the compiler, but if it's detail brushes you better caulk it. If it's a model I'd go with removing those faces, as in this case, as with detail brushes, the triangles will probably be skept by the 3d card culling BUT (this is a huuuuge but) they will still be copied into card's memory at rendering each frame, which in the actuallity is the biggest slow down in renderers without VBOs (like q3).

[^misantropia^]

If it's structural brushes then basically you can ignore it, because those faces will be removed in the compiler

Only if the compiler is absolutely sure that the faces will always be invisible. The approach used by q3map2 is not so great (let's call it conservative) so YMMV.

If it's a model I'd go with removing those faces, as in this case, as with detail brushes, the triangles will probably be skept by the 3d card culling BUT (this is a huuuuge but) they will still be copied into card's memory at rendering each frame

No. The engine culls invisible faces before uploading the model's trisoup to the GPU.

[jal_]

misantropia, it doesn't cull them. It copies the whole meshes vertexes arrays. If it had to do the checking to each triangle being front or back to the camera matrix the copying process would be even slower. It does cull bsp leafs, but that only works for brushes, not model trisoups.

[^misantropia^]

You're right. I thought R_RenderView() culled invisible faces but it doesn't. Only for mirror scenes, strangely enough.