How optimized should my first alpha be? It will have full skyboxes and lighting, but I don't know how intricate I should be with optimization. Should I use areaportals, hint brushes and the works, or just let it create its own visleaves? I mainly want to focus on blocking out my map for now.
First Alpha optimization question
- Thread starter Portalman4
- Start date
seth
aa
- May 31, 2013
- 1,019
- 851
I'd say you should do the works. You probably don't need it since I hope that your alpha is devoid of major detail, but it's good practice to get a good optimized foundation for your map.
Don't go crazy on the hints as those are pretty time-consuming and are very susceptible to change with your layout, but I'd make sure to get some areaportals in and especially func_details.
Don't go crazy on the hints as those are pretty time-consuming and are very susceptible to change with your layout, but I'd make sure to get some areaportals in and especially func_details.
Thanks! I'll keep this in mind.
Func_detail is probably your number 1 entity in alpha maps. Not only does it help performance in-game, it also cuts down on compile time since VVIS is just skipping brushes tied to a func_detail when it calculates visibility.
I always go with early alpha maps being func_detailed and having areaportals. No hint brusher, no occluders, nothing. Only when I'm fairly certain my layout is good I go ahead with the hint brushes and occluders and whatnots since I'm far less likely to significantly change the layout and having to redo most of my hinting and such.
I always go with early alpha maps being func_detailed and having areaportals. No hint brusher, no occluders, nothing. Only when I'm fairly certain my layout is good I go ahead with the hint brushes and occluders and whatnots since I'm far less likely to significantly change the layout and having to redo most of my hinting and such.
Yeah sorry but they does, the thing is, if you don't use func_detail, every brushes that should be func_detailled will create way more visleaves, thus the rendering engine will have to do more calculation because of those extra (and useless) visleaves.
- Sep 5, 2009
- 912
- 684
You're misunderstanding him and how visleaves work. All that calculation of what should be rendered is done on the compilers end, it just makes it easier on you to func_detail. In game the brushes are still just rendering textures, irrelevant to it being a func_detail or world brush.
nightwatch
aa
- Sep 7, 2012
- 638
- 500
Yes, but to say it has no effect is technically wrong. If the engine has to traverse a list of 5,000 visleaves rather than a list of 500, there is a slight performance loss, even if negligible. In addition, file size and map loading times will be affected (though once again, not in any meaningful or alarming way)
- Sep 5, 2009
- 912
- 684
Of course, but I'm going off the assumption someone's building a map and not trying to break the engine intentionally.
The effect of func_detail is to have a brush entity that does nothing. Keyword being ENTITY. You could use any other brush entity and get the same effects of a func_detail. (Obviously you would have the effects of the chosen entity as well.) Ingame, func_detail basicaly doesn't even exist.
I think people here are trying to make sure the OP understands that making a lot of things in your map a func_detail does not positively affect performance, but rather would affect it negatively because more would probably be drawn. Sometimes people misunderstand that func_detail is a magic brush that somehow takes less resources to render. In reality, when the map is compiled it becomes an ordinary world brush. The only significant difference between it and a world brush is in Hammer where, as some have said, it doesn't create visleaves upon compile. This makes sense because func_detailed items are usually quite small and incapable of blocking a player's line of sight, and so for them to cut leaves is unnecessary. Sometimes it is beneficial to leave world brushes alone as the visleaves they create can help break up rendered space, and help combat light bleeding and unrealistic shadows, if they are touching another brush. E.G. A pillar or structural beam that sits against a wall.
But I think in an early alpha, a map isn't likely to have many items of fine detail that qualify. An early alpha is likely to be composed of mostly large blocks. Some examples of things that could be func_detailed are steps and very small ledges because they have no role in blocking player sight. The large blocks are best left as world brushes because they will block player vision and so it makes sense for them to cut leaves.
Since an alpha map is devoid of most fine detail, I do not think it necessary to build any hint faces, unless they are outside in large spaces. Area portals and areaportalwindows are very useful in doorways and passages but will not work unless they are enclosed by world brushes. I think, as soupcan said, those should be the least of the visibility optimisation tools you engage with.
There is also a lot to be said for building a map with visibility in mind. Long sightlines through multiple rooms/areas should be avoided as they cannot be culled if a player can see them. Using large world brushes to create environmental corners, U-turns and S-bends is very good. Also notice how in Valve maps, doorways sometimes do not open straight out in to an area, but sideways. If you plan these things well, you will find visibility optimisation easy.
But I think in an early alpha, a map isn't likely to have many items of fine detail that qualify. An early alpha is likely to be composed of mostly large blocks. Some examples of things that could be func_detailed are steps and very small ledges because they have no role in blocking player sight. The large blocks are best left as world brushes because they will block player vision and so it makes sense for them to cut leaves.
Since an alpha map is devoid of most fine detail, I do not think it necessary to build any hint faces, unless they are outside in large spaces. Area portals and areaportalwindows are very useful in doorways and passages but will not work unless they are enclosed by world brushes. I think, as soupcan said, those should be the least of the visibility optimisation tools you engage with.
There is also a lot to be said for building a map with visibility in mind. Long sightlines through multiple rooms/areas should be avoided as they cannot be culled if a player can see them. Using large world brushes to create environmental corners, U-turns and S-bends is very good. Also notice how in Valve maps, doorways sometimes do not open straight out in to an area, but sideways. If you plan these things well, you will find visibility optimisation easy.
Yeah, I mean that's true, but it's really hard to create a map where the client calculating what visleaves to render actually degrades performance. You'd have to be compiling for days to get a map that unoptimized. The primary function of func_detail is really to reduce compile time--otherwise you'd just use hints over weird geometry for visleaf creation--and they don't do anything by themselves in game.
Maybe I should have said that it doesn't affect anything else in game--only itself.
Last edited:
Yeah I know it's really picky, and actually I don't know if there is real difference between a func_detailled map and one without them, but actually that's how it works :lol:
ConradBenderfry
L1: Registered
- Jul 13, 2013
- 21
- 2
For the first alpha func_detail, nodraws and complete leak seal should do the trick. I usually stay away from hint and area portal textures until I have a concrete layout done. VVIS on "Normal" is usually enough. Though I recommend you to be tight with skybox sealing, it will be much easier to modify it later on. Don't forget to cover your displacements with nodraw brushes if you decide to introduce them in your first Alpha, as they don't seal leaks.