Hypothetical: I'm making a map that's got lots of brush faces. I mean, LOTS of brush faces. Probably too many brush faces once it's all complete. What are the downsides of using lots and lots of props to decorate with? Is there such a thing as too many models?
- Sep 10, 2016
- 531
- 398
I've heard people say that performance these days (in source, at any rate) is limited a lot more by draw calls than the raw number of polys.
So, if you're spamming a bunch of props, each prop is creating a new draw call for its UV, which is a lot less efficient than brushes which can be combined a lot more by VBSP.
This is all a little (citation needed), though - just what I've heard here and there and inferred through basic logic.
So what you can do to fix this is to combine the props in each unique "area" of your map (which valve did for de_nuke in 2016 to help performance), so all the props in that area share one UV and thus only create one draw call - the disadvantage is that this UV will be MASSIVE, so you'll end up compromising the map's filesize a lot more than if you had left the props uncombined, especially if you would only be reusing a small set of the same props if you weren't doing the combine method.
It's also harder to optimise, since the ENTIRE prop will be visible if any part of its bounding box is, whereas with a lot of smaller props you can cull each individual one with areaportals and just good VVIS practice.
Another general disadvantage of using a bunch of props is that props are vertex-lit by default, which is almost always lower quality than the lightmapped equivalent. You can force props to use lightmaps, but by default props made with Propper will look horribly broken when lightmapped. Here's a thread on how to fix that.
Come to think of it, I'm pretty sure Propper props just point at the base-game texture you used on them, so they end up coming at virtually no filesize cost.
But if you fix them up to be lightmappable, you are by definition creating a new and unique texture for their UV, so then their filesize cost starts to become significant.
So you basically have to choose between good lighting and good filesize.
Good lighting is usually the preferable choice - within reason, since you don't want a 90 MB map.
You may notice that I only have one published map above 50 MB (pl_boatload), and it's 55 MB. Not exactly hard-hitting...
So, if you're spamming a bunch of props, each prop is creating a new draw call for its UV, which is a lot less efficient than brushes which can be combined a lot more by VBSP.
This is all a little (citation needed), though - just what I've heard here and there and inferred through basic logic.
So what you can do to fix this is to combine the props in each unique "area" of your map (which valve did for de_nuke in 2016 to help performance), so all the props in that area share one UV and thus only create one draw call - the disadvantage is that this UV will be MASSIVE, so you'll end up compromising the map's filesize a lot more than if you had left the props uncombined, especially if you would only be reusing a small set of the same props if you weren't doing the combine method.
It's also harder to optimise, since the ENTIRE prop will be visible if any part of its bounding box is, whereas with a lot of smaller props you can cull each individual one with areaportals and just good VVIS practice.
Another general disadvantage of using a bunch of props is that props are vertex-lit by default, which is almost always lower quality than the lightmapped equivalent. You can force props to use lightmaps, but by default props made with Propper will look horribly broken when lightmapped. Here's a thread on how to fix that.
The thing that breaks lightmaps on props is any case where the prop is reusing the same UV for multiple parts of the model - the lightmaps are saved directly into the UV, so it can't make different lightmaps for the different parts of the prop.
Here's an example of that with the train tunnel prop:
You can see that the shadow from the sunlight is somehow on both sides when it really shouldn't be, and the shadow from the palm tree is on both sides too, one of which doesn't even have a palm tree to cast a shadow.
This indicates that valve built this model (in 2008) by creating the UV and geometry for one side, and then just mirroring it to create the other side - thus saving on UV space and model filesize. Of course, they had no idea it would break this prop when used with the lightmapped props feature they would go on to add in 2014.
Here's an example of that with the train tunnel prop:
You can see that the shadow from the sunlight is somehow on both sides when it really shouldn't be, and the shadow from the palm tree is on both sides too, one of which doesn't even have a palm tree to cast a shadow.
This indicates that valve built this model (in 2008) by creating the UV and geometry for one side, and then just mirroring it to create the other side - thus saving on UV space and model filesize. Of course, they had no idea it would break this prop when used with the lightmapped props feature they would go on to add in 2014.
Come to think of it, I'm pretty sure Propper props just point at the base-game texture you used on them, so they end up coming at virtually no filesize cost.
But if you fix them up to be lightmappable, you are by definition creating a new and unique texture for their UV, so then their filesize cost starts to become significant.
So you basically have to choose between good lighting and good filesize.
Good lighting is usually the preferable choice - within reason, since you don't want a 90 MB map.
You may notice that I only have one published map above 50 MB (pl_boatload), and it's 55 MB. Not exactly hard-hitting...
Last edited:
