- less shadow throwing props/less props overall
- less lights
- erase every face, vertical and line that doesn't has to be in the map
- A great occlusion geometry and smaller rooms :P
- 1-2 cinematics are fine at one spot, 10 bunched together look awesome, but eat performance
- Everything has to be loaded, so using a few props is better than using every prop the editor offers to you
- i don't know if its still a problem, but too many sounds can lead to microlag when the PC has to load too many too fast (like entering a room and loading 5 new sounds can bring down old PCs)
Evil_bOb1Join Date: 2002-07-13Member: 938Members, Squad Five Blue
Occlusion Geometry if you haven't done already. Being careful about the range of visible things at any one time is very important. Corridors with strange angles to them are most often to avoid being able to see from one room to another. Small doors with the associated corridor can also sort of achieve the same result as you offer a framed view into a room, allowing the player to have a view into the distance, but only a slice into the ahead room will be rendered. You basically want to avoid having multiple rooms rendered at a time, and make do in consequence. If you know a room is going to be big and detailed, heavy on the computer's resources, makes sure it is isolated from view when not in the room in question. That it only becomes visible at the last moment for a player. If you know the rooms and corridors are less demanding, you can chain them without to much problems.
Throughout the process, you need to check r_stats continuously. Knowing the technical constraints of the engine is essential. You need to learn how the engine works and work with it, not against it. It is essential that the map doesn't eat up all of the resources because there will be many more things in the map once a game is played; players, structures, entities...
If you have experience with older engines like goldsrc it definitely helps, as a mapper had to be much more conscious about these things back then.
In short, every move you make as a mapper has effects on performance. The more variance you use in textures and props, the more resources the map needs. The more detail you put correlates with performance. The number of lights comes into account too. Everything comes into account. So learn to makes more out of less. Learn how to touch your map lightly to achieve heavy gameplay and visual impact.
Making a map asks a lot from the mapper, but you need to remove yourself from your project. Its not about what you want to do, and its not about showing off your mapping skills. Its about the game, and people who want to have fun. It is essential that they are your focus. The more your sensitivity about this grows, combined with an understanding of the 'virtual matter', the more you'll know about the middle way. And when things are done with balance, proper performance will follow.
There isn't an equation that will tell you how to increase performance, its a core constraint of mapping you need to understand with your own sensitivity.
The biggest performance hog can be lights, since they're fully dynamic, so try to use them as necessary (ie. don't use too many in a single room). Remember to disable specularity in lights that are meant for general ambience instead of actual direct lighting or simply not noticeable, as that also affects performance. The distance of the lights also affect performance a bigger radius/distance can be a problem, you may need to adjust this -- but in other cases you can merge two lights into one with a bigger radius and it'll be an improvement in performance.
Since Spark uses Deferred Shading iirc, the cost of lights get more expensive the more pixels they light, so keep your light radius small, try not to let too many lights overlap and keep shadows to your key lights.
I would very much like a tutorial on occlusion geometry, anybody up for it? In detail I'd like to know
- What occusion geometry is/does (the theory)
- How it works in the editor (practical application)
- Ways to check if the whole thing actually works as intended (in-game I guess)
- Examples for when it it useful to use occlusion geomerty
- Examples when you should not use occlusion geometry
I'll try to answer, however please understand there are those on these forums more knowledgeable that might be able to give a more concise or detailed answer.
What is occlusion geometry? This is geometry that is placed into the map specifically for the purpose of limiting the amount of the level that each player renders based on their current visibility. The goal is to improve performance vs rendering the entire map all the time.
How does it work in the editor? In order to be properly parsed by the game, all occlusion geometry needs to be placed into a layer (not group!) called OcclusionGeometry. I'd highly suggest checking how other maps use occlusion - they should have a separate group & layer so you can view it and see how it interacts with the real level. Basically you want it to be close to the room & hall geo as much as possible to maximize performance saving. The other thing to note is that occluded faces will show straight to the skybox, regardless of there being other geometry, as it will stop rendering past that face.
How do I check how its working? In console use the command r_wireframe 1. Now you should be able to see what is currently rendered behind the faces/props you are immediately looking at. If it's the whole map something went wrong. The rule that I've heard to check performance is you should check r_stats and make sure draw calls are under 1800.
When should you use it? Always - your whole map should be entailed within occlusion geometry. I check for errors in the editor before testing by selecting all occlusion geo, and then turning perspective view to normal and 'walk' through everywhere in the map - if you see any selected blue faces going through your walls then you need to fix it.
When you should not use it? Make sure you do not cut off any visible area to another with occlusion geo - e.g. if you leave an occlusion face in a doorway you will not be able to see the room or anyone on the other side of that occlusion face in game.
In NS1 Hammer ran a vis check and created this information for you - now you tell the game exactly what vis should be.
Back in HL1/GoldSrc I remember to put "vis blocker" lines in the middle of corridors, etc. to divide the map into sectors. the game would then only render the sector you were in and those directy adjacent to it.
The way I understand your explaination however the occlusion geometry in Spark is placed OUTSIDE of the actual map to "intercept" parts where the player can - for some reason - look beyond the boundaries of the room/corridor/level. To me this sounds more like a "safeguard" to make sure "leaks" in the level geometry don't cause huge rendering loads - it doesn't sound like a "tool" that mappers can deliberatly use to influence rendering and thus performance. Is this assertion correct? If I design my level in a way where there are no "leaks", but every part of the rooms are covered either by faces or props, there should be no need for occusion geometry, should there?
btw: does occlusion geometry block the players movement? And does it block the view for spectators are well? (might be usefull for hiding your readyroom secret room from people flying around in spectator mode.
Oh you're right - I forgot about setting up the vis blockers for it to parse.
It's not so much as a tool as a requirement - the normal geometry & props will NOT block vis, so without occlusion everything is a vis leak. You can see this when you check the wireframe.
Occlusion geometry does not block players movement, but will affect what they can see. e.g. I recently had issues with the ends of vents being cut off, so you would see the skybox instead of the vent until you go through the occluding face. Or check skylight thread, Flat pointed out an error where skulks could disappear from view (otherside of occlusion). Spectators do see it but can go outside of the occlusion geometry. Secret rooms are easy to find and not worth trying to hide outside of normal false prop, as eventually someone will eventually open the .level and find it. That said the 'secret room' in skylight still remains fairly secret despite players in it being visible to the rest of the rr, possibly because it's not that interesting.
The game is rendering everything. Only the OG is telling the game where to stop. That means if you are in the readyroom and look in the direction of the rest of the map, it will render everything. Surround the readyroom with OG and it will only render stuff inside the box of faces you designated as OG. I make my OG orange, that makes it easy to check by walking through the level. If you like, just look at my yakushima map for getting an idea how it works. But make sure you check the layers and switch it to visible.
I tried to keep the draw call at around 800-1000, but it is more in big rooms. 1000 is good for performance and old computers. 1800 could be a bit too high.
It's not so much as a tool as a requirement - the normal geometry & props will NOT block vis, so without occlusion everything is a vis leak.
Are you sure about that? If that is true, that would be really really disappointing.
I remembered viewing an old blog post where Max talked about occlusion and found it here:
It seems that way back in the beta the engine was intended to calculate what to render and what not. Forcing mappers to "wrap" levels in occlusion geometry not only is kinda unintuitive it also feels very much like a quick&dirty "crutch". I'm a bit sceptical about the whole thing, but I guess I'll just have to take your word for it (unless some dev accidently wonders into these forums and can elighten us).
I tried to keep the draw call at around 800-1000, but it is more in big rooms. 1000 is good for performance and old computers. 1800 could be a bit too high.
Oh I should clarify - 1800 should be the very max that you should ever go. Sentinel is correct most places should be around 1000 for good performance. You will exceed this in large rooms but you should not exceed 1800.
@Solaris - they changed how occlusion works since the early beta.
It's not so much as a tool as a requirement - the normal geometry & props will NOT block vis, so without occlusion everything is a vis leak.
Are you sure about that? If that is true, that would be really really disappointing.
I remembered viewing an old blog post where Max talked about occlusion and found it here:
It seems that way back in the beta the engine was intended to calculate what to render and what not. Forcing mappers to "wrap" levels in occlusion geometry not only is kinda unintuitive it also feels very much like a quick&dirty "crutch". I'm a bit sceptical about the whole thing, but I guess I'll just have to take your word for it (unless some dev accidently wonders into these forums and can elighten us).
That's how it used to work, but it didn't really do a great job. UWE effectively went back to the manually-created occlusion geometry as it gives the mappers maximum control over their maps. The downside is that its a tedious process.
My suggestion is to start with the easiest occlusion geometry (e.g. a big box around your map) and then add complexity as needed. From testing, you'll find some rooms need more occlusion culling than others to get acceptable performance, so no need to go occlusion geometry crazy from the start.
xtcmenJoin Date: 2004-04-20Member: 28040Members, Squad Five Blue
Honestly making occlusion is the easiest part of mapping. All you are doing is making a nice box.
The trick is to make sure there are no lines of sights through multiple rooms. Because if there are, then the game will render all the rooms that you can see from a tiny hole.
This requires clever planning, clever greyboxing, and a bit of luck. But if you catch all the line of sight issues early on while you are greboxing, you shouldn't run into any problems.
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
edited May 2013
Apart from number of lights having a big impact, Spark is optimized for short distance high detail rendering, lacking any kind of LoD models (lower detail on distant models/textures). The general rules for Goldsrc and Source still apply here. Rules like visblocking, keeping an eye on the lines of sights xtcmen mentioned.
However, you have to do the vis aspect that was automatically generated in those engines and could be influence using hint/skip brushing. OcclusionGeometry should be used for visblocking in Spark...
Comments
- less lights
- erase every face, vertical and line that doesn't has to be in the map
- A great occlusion geometry and smaller rooms :P
- 1-2 cinematics are fine at one spot, 10 bunched together look awesome, but eat performance
- Everything has to be loaded, so using a few props is better than using every prop the editor offers to you
- i don't know if its still a problem, but too many sounds can lead to microlag when the PC has to load too many too fast (like entering a room and loading 5 new sounds can bring down old PCs)
Thats all I can remember right now
Throughout the process, you need to check r_stats continuously. Knowing the technical constraints of the engine is essential. You need to learn how the engine works and work with it, not against it. It is essential that the map doesn't eat up all of the resources because there will be many more things in the map once a game is played; players, structures, entities...
If you have experience with older engines like goldsrc it definitely helps, as a mapper had to be much more conscious about these things back then.
In short, every move you make as a mapper has effects on performance. The more variance you use in textures and props, the more resources the map needs. The more detail you put correlates with performance. The number of lights comes into account too. Everything comes into account. So learn to makes more out of less. Learn how to touch your map lightly to achieve heavy gameplay and visual impact.
Making a map asks a lot from the mapper, but you need to remove yourself from your project. Its not about what you want to do, and its not about showing off your mapping skills. Its about the game, and people who want to have fun. It is essential that they are your focus. The more your sensitivity about this grows, combined with an understanding of the 'virtual matter', the more you'll know about the middle way. And when things are done with balance, proper performance will follow.
There isn't an equation that will tell you how to increase performance, its a core constraint of mapping you need to understand with your own sensitivity.
Hopefully that helps a bit.
I would very much like a tutorial on occlusion geometry, anybody up for it? In detail I'd like to know
- What occusion geometry is/does (the theory)
- How it works in the editor (practical application)
- Ways to check if the whole thing actually works as intended (in-game I guess)
- Examples for when it it useful to use occlusion geomerty
- Examples when you should not use occlusion geometry
Thank you for your answer so far.
Back in HL1/GoldSrc I remember to put "vis blocker" lines in the middle of corridors, etc. to divide the map into sectors. the game would then only render the sector you were in and those directy adjacent to it.
The way I understand your explaination however the occlusion geometry in Spark is placed OUTSIDE of the actual map to "intercept" parts where the player can - for some reason - look beyond the boundaries of the room/corridor/level. To me this sounds more like a "safeguard" to make sure "leaks" in the level geometry don't cause huge rendering loads - it doesn't sound like a "tool" that mappers can deliberatly use to influence rendering and thus performance. Is this assertion correct? If I design my level in a way where there are no "leaks", but every part of the rooms are covered either by faces or props, there should be no need for occusion geometry, should there?
btw: does occlusion geometry block the players movement? And does it block the view for spectators are well? (might be usefull for hiding your readyroom secret room from people flying around in spectator mode.
I tried to keep the draw call at around 800-1000, but it is more in big rooms. 1000 is good for performance and old computers. 1800 could be a bit too high.
Are you sure about that? If that is true, that would be really really disappointing.
I remembered viewing an old blog post where Max talked about occlusion and found it here:
It seems that way back in the beta the engine was intended to calculate what to render and what not. Forcing mappers to "wrap" levels in occlusion geometry not only is kinda unintuitive it also feels very much like a quick&dirty "crutch". I'm a bit sceptical about the whole thing, but I guess I'll just have to take your word for it (unless some dev accidently wonders into these forums and can elighten us).
The trick is to make sure there are no lines of sights through multiple rooms. Because if there are, then the game will render all the rooms that you can see from a tiny hole.