occlusion culling
<div class="IPBDescription">how to</div>I see a lot of talk about Occlusion culling, but i have no idea how to implement it or really what it does other than hid parts of the map that aren't meant to be rendered. Can someone please offer me some insight into this and how to use it please?
:-)
:-)
Comments
Its pretty much like you said, it makes it so hidden objects aren't rendered but its calculated by the engine itself in spark if im not mistaking.
You just have to make sure you don't have any holes or strange spots in your maps that let you see parts of the map that you otherwise wouldn't see.
because that would cause the engine to render those models and geometry even though they aren't needed, causing TEH LAGZ if its to much.
Basically you have to envelop your map as tight as possible with geometry in a group called OcclusionCulling with faces on both sides. Open one of the official maps, or a functional community map and take a look. It is probably the best way to understand how it works.
A community map might be easier to understand as UWE's maps are really rich and complex! In ns2_turtle OcclusionCulling is in a layer named Occ. Geometry in a layer called Geo, by turning these on and off you should be able to understand how they relate to each other.
Props won't be rendered if behind an OcclussionCulling face. With geometry it is a bit different, as it seams spark cuts up the geometry into different parts so sometimes geometry is rendered behind Occlusion faces if it is close to the player.
In-game, use the console command r_wireframe (with cheats 1) to take a look at what the engine renders.
The purpose of this is to speed up the calculation of culled geometry eliminating both the lag caused by the geometry and the automatic culler. Whilst it's not a necessity, it's good practice to include it and it will also increase performance of the map.
Not to do some savage personal advertising but simple community maps like ns2_turtle are the only maps that runs reasonably nicely on my comp, I love to play the official maps too, and they are visually stunning but I get terrible performance on them... I get criticism about how the visuals could be much nicer on turtle, but I want to make a map that at least I can play on :p
If NS2 doesn't perform much better, it will stay a game for hardcore gamers with top of the line gear.
/edit
I have a question for UWE mappers, how many draw calls do you limit yourselves to? With turtle I have tried to stay under 1000 and it is there in the biggest areas. With UWE maps it can go way higher.
What is the internal limit on draw calls UWE sets for its mappers?
So once again, the occlusion mesh <i>is</i> now a necessity.
Evil_bOb1: We don't have any internal rules regarding draw calls at the moment. Since performance is still changing on a very regular basis, if we started to set firm limits like that we'd just be chasing moving targets all the time. When things even out a bit we might look into where the performance sweet spot is for draw calls but right now we aren't too worried about it.
:-)<!--QuoteEnd--></div><!--QuoteEEnd-->
There are two major aspects to this. You need the afforementioned "OcclusionGeometry" group. If you can actually see something, then it can't be culled, obviously; so you've got to use rooms and corridors that obstruct view so that which is behind can be culled, but you have to figure out how to do it in an aesthetically pleasing way that doesn't look like you just put something there for the sake of occlusion culling.
I have never seen draw calls be a bottleneck in the game, but I would recommend keeping it under 1000.
So once again, the occlusion mesh <i>is</i> now a necessity.
Evil_bOb1: We don't have any internal rules regarding draw calls at the moment. Since performance is still changing on a very regular basis, if we started to set firm limits like that we'd just be chasing moving targets all the time. When things even out a bit we might look into where the performance sweet spot is for draw calls but right now we aren't too worried about it.<!--QuoteEnd--></div><!--QuoteEEnd-->
in that case i apologize for the miss information, i havent been able to play or map for ns2 for the last 4 months because my gpu broke and i havent had the spare cash to fit it.
I did it for one room, it was kinda tedious but not like skyboxing in HL2. Made 100% difference in performance. I found it not possible to select everything in a layer and then group it. So I ended up with the inside facing Oc and outside being different groups. How can you merge groups now?
Good job UWE : )
As OccGeo is usually one mesh, you can also double click on any face of it to select any connected face, then add to the OccGeo group. This is how I do it so I am sure when I edit the OccGeo that all new elements are included.
Max, you say that draw calls are not the bottleneck, which I agree I have noticed, but when you take in account everything else that it is going to run in parallel, having a limit on draw calls can smooth things out considerably. Wouldn't it be a good thing for the game, for the team to set a limit on draw calls? Tram can easily go over the 2000 and it is not rare that it goes over 3000. Beautiful map but terrible performance.
Are you confident that after optimization of the game code, that 3000 draw calls be viable?
You do that doubled version, then add it to a group (F8 shortcut key on editor for group window) named exactly OccusionGeometry
Here is how I did mine on turtle. Now, this is not THE way to make OccGeo. It was adapted to the geometry on turtle and there might be an easier way for each depending on the map. It is good to figure things out by oneself, so then you understand why you do it that way. But it is also good to share so it will be easier for you guys :D
-First I created a huge rectangle under the map, larger than the extents of the map.
-then drew on that rectangle with the line tool the contours of the rooms. Starting with the first line in perspective view then followed in top view once I knew the lines were going to connect and draw on that rectangle. (It doesn't always work that way so check every once in a while in perspective view that the lines are creating on the bottom face)
-Once I got the right shape to enclose a room. I duplicated that shape twice and put the two faces just above and below the room it was going to enclose. Keeping the original if ever.
-Then I joined the two faces with the line tool to make a volume.
-Then I created all the missing faces
-Double click on the mesh and add to OcclusionGeometry group
To connect two volumes, it becomes a bit trickier.
-I would draw a rectangle a bit bigger than the connecting way on the face I want to make a hole in. Delete the center to get a hole.
Now here is where it get tricky because spark doesn't recognized the lines of the hole on both sides.
-Create another rectangle smaller than the first. Delete the center then move the edges so it is the same size as the first. So now I effectively have holes on both sides.
-Repeat this on the other room you want to connect.
-Connect the two holes and create faces where they a missing.
-double click on the mesh and add to OcclusionGeometry group.
Using this method I was able to create my Occ for the whole level in a few days