PDA

View Full Version : [TF2] Dealing with large spaces


Fujikanaeda
12-16-2007, 02:57 PM
So, I'm working on a new game variant, but it requires a lot of open space, an optimization nightmare, I know! The only enclosed parts of the particular map I'm working on are the actual Red and Blu respawns. However, for overall effect, I've thrown in a couple of windows for each of the respawns so that players can view the "field of battle" before entering.

I've covered up these windows with func_areaportalwindow brush entities and tied these properly, along with adding a func_areaportal tied to a trigger_multiple on the actual exit of the respawns. Should this method give me any decrease in vvis compile time? I tried hinting off these respawns to try to reduce the compile time, but it still seems to take something on the order of three forevers (I left it running for 6 hours and it hadn't finished) for PortalVis to finish off. In order to actually get a compile going on it at this point, I've got to run a fast compile with vvis, which doesn't seem to have any noticeable errors.

Prior to adding these respawns, the dimensions of the wide, open space was the same, and I was able to get quick compile times (2-5 minutes, if that). It seems that only after I added my respawn areas that the vvis compile time went up exponentially, and these respawn areas are relatively small spaces! Does anyone have any ideas on why the vvis compile time went up so dramatically with such little change? Should I implement a different method of cutting off the leaves for the respawn rooms? (Note: I have read the optimization articles and implemented many of these techniques but have not had any success in speeding up compile times)


Another note: has anyone had any success with implementing dynamic cameras into TF2? I've been toying around with this, because it seems that the point_camera and func_monitor entities are missing from the TF2 fgd, by making entities for them and adding in their keys and values by hand but I haven't had any success. Has anyone been able to implement a workaround?

Thanks!

PuddingWagon
12-17-2007, 07:14 AM
The only thing that I can think of is that you forgot to use func_details in the spawns, although you have read the optimisation guides so they should have had this in there. Just in case you skipped it or it wasn't in the guides (and for anyone who hasn't heard of this entity):

Func_detail brushes are skipped by VIS, the do not add to the time taken for that stage of compile. They are very important since they also save on world polygons. Actually links would be easier for me:
Func_Detail (http://developer.valvesoftware.com/wiki/Func_detail)
Compile Times (http://developer.valvesoftware.com/wiki/Controlling_Geometry_Visibility_and_Compile_Times# Detail_brushes)
BSP Map Optimisation (http://developer.valvesoftware.com/wiki/BSP_Map_Optimization#Detail_Brushes)
Geometry Optimisation (http://developer.valvesoftware.com/wiki/Optimization_%28Geometry%29#Detail_brushes)


It is possible that the use of func_areaportalwindow and func_areaportal in the same area confuses VIS, try removing these then compiling. Remember though Hint brushes and areaportals don't speed up compile time, they increase in-game performance at the cost of some additional compile time. Saying that, it shouldn't take 6 hours+ for a relatively simple map. If it is just open space (not many world brushes cutting it up) then it would not take 6 hours.

Don't forget to check the compile log for errors, even though you didn't complete the compile (let it get up to the VIS stage, then end task it, then check the log).

How large are we talking here btw?
You could cut down the actual volume of the space by making the sky height less, just make sure that it is still out of grenade range or else it looks a bit dodgy. This will cut down on the compile time.
Hope some of this helped mate.