|
|
Okay, so I have realized that my map is going to take fairly long to compile due to it's final size that I want. I have read several articles about some optimization techniques, and now I have some questions. So here we go!
1. Viscluster. Most of my map is outdoors, and according to Valve Developer Wiki, I can use this brush to lessen decompile time when there is a big outdoor place. How exactly is this used, and can it be used in multiplayer?
2. func_detail. This turns a brush into something easier to render apparantly, but I'm not sure what should and should not be turned into a func_detail. From what I understand, it is any part of a room that is not that floor, walls or ceiling, regardless to where they are in the map. Is that right?
3. I am using overlays throughout the majority of the map because they indicate a path that the player should follow. Because there will be a lot of overlays, (a lot of them) and because overlays are taxing (or so I've heard), should I just make a bunch of custom textures for the paths, (I will have to make a LOT of textures if I do that) or are overlays not really that taxing?
4. Displacements. I was reading an aticle about displacements, and I got the impression that even if the terrain appears to be bumpy, the player will clip through the displacements, as if the ground was flat. Is that true or did I just read wrong?
5. Cylinders. I know that the more edges they have the more taxing they are, but for the sake of looks, should it have more or less edges? I want the cylinders to look like columns, so should they have lots of edges or not? (I know this isn't really about performance but I just want to know)
6. Will having a large amount of func_pushes throughout the map (roughly around 25 to 30% of the map) make poor performance?
That's all for now. Sorry for asking so many questions, I just want to know to get the best I can out of my map. Thanks to whoever answers!
|
1) Not entirely sure what you're referring to so I'll have to have you elaborate a little on it.
2) You definitely want to func_detail complex shapes like spheres, arches, cones, etc. This allows the compiler to not have to create portals for every aspect of that complex shape (which is really taxing). However, world geometry blocks visibility for the vis calculations. Think of it as having to forms of vision, regular and X-ray. What that basically means is if you have a wall that is world geometry, it blocks all of the stuff behind it from being rendered,so that it's only drawn if player can see it based on the visleafs (basically if the player can't see it w/ regular vision it won't get rendered). If you make this wall a func_detail the engine will render everything behind it whether the player can see it physically or not as there is nothing to block the line of sight for the X-ray vision. Hopefully that makes some sense...
3) Not sure.
4) If there are small changes in elevation then this won't be too big a deal and probably does, in fact, clip it in a similar manner to what you described. However, I'm sure you've tried some cusom maps where you get inexplicably stuck in certain parts of terrain b/c of the way the displacement was made. If the vertices have too drastic a change in elevation you simply won't be able to make it from one to the other. You need to make sure that the terrain is smooth enough to be passable, yet "bumpy" enough to give the desired effect. Or you could always player clip certain trouble spots if you want to keep a certain look.
5) There are ways to make perfectly smooth columns w/o using the cylinder tool which relies on displacements and subdividing. I won't go into the details on that here, but as far as the question is concerned it really depends on how noticeable the column is in the first place. Is it a cylinder that forms a column for the main entrance of a building and as such, will be seen quite often? Or is it something small like some little columns holding up a handrail for a bridge? Obviously the more noticeable it is the more you'd like it to be detailed, but don't hesitate to cut corners on it if it's something that most people won't notice during gameplay anyway. Also take into consideration how much traffic will be on that part of the map during normal gameplay, you definitely don't want to overdo things if it will cause a reduction in framerate just to make it look pretty.
6) Not sure, though I would be inclined to say no. It also depends on how much 30% of the map actually is, if it's a small map like Billiards I'd say you're ok either way, if it's a map on the scale of warpath it may actually be a problem. I think quantity would be more of a problem than sheer size, so again, it really depends on what you mean by 30% of the map.
|
Okay, thanks Milky. The explanation for #2 REALLY explained it to me well. Thanks.
As far as viscluster. I read on the valve wiki page that it tells that VVIS that all of these brushes can see eachother, and by telling it that before the compile it saves a LOT of time by preventing a lot of calculations. Apparently it's mainly used in large outdoor areas, and most of the map (which will be quite large. If I had to guess... about all of the grid looking from the top view, about 1/4 of the hight of the grid. Hmm... I might have to do something about that.)
I'll just decide as far as the overlays myself. Hopefuly it shouldn't be too much of a problem.
And the columns are in the room where everyone spawns. There is one in each of the 4 corners.
|
If there are only 4 in a spawn room and you have them blocked off vis-wise from other portions of the map I'd say go for a little more detail on them, but make sure you func_detail them. I'd be surprised if they affect too many people in that location with so few.
As for the other I'm not to sure, but I'd bet there are others here that probably know.
|
1. I'm testing it out to see exactly how it works, but it seems like you just select a bunch of brushes in one big open space (only if they are all enclosed in the same big open space, and can see eachother), and make them all into one big func_viscluster. I'm trying it to see though. 2. Pretty much make anything that isn't part of the layout should be a func_detail. 3. Don't know 4. It sounds like you misunderstood part of it. Displacements won't get used by the part of the compiler that deals with the visleafs. They are solid from one side only (meaning if a player is under one, he can jump right through it. On the other side of it, the solid side, you will stay on top of the displacement the whole time, provided that it isn't too steep. not too sure on the last two.
|
If you're stringing lots of overlays together in a line to make your road, then you could get rid of some of them. The Ustart, Uend, Vstart and Vend properties are what controls the parts of the overlay that get used, so Ustart at 0, and Uend at 5 would make the overlay repeat 5 times in that direction.Vstart at 0 and Vend at 7 would make it repeat 7 times in the other direction.
So by dragging the shape of the road overlay to 10 times its normal length, and using a value of 10 for the relevent property, then you get a 10x length of road that doesn't looked streached, and only uses 1 overlay. Sort of awkward to explain without pics.
|
Wow, lots more help than I thought I'd get. I'll be sure to check out those articles! Now if I could just get the loops and corkscrews to work. I think I have a solution though.
|
|
|