Zacker Posted December 14, 2006 Report Posted December 14, 2006 Yeah ok like that then you will get what I said, increased polycount and increased memory usage. Only slightly more I know, but still the so called performance tweak includes some performance hits. The gain might be bigger than the loss, I just haven't believed so so far. I will see if I can find time to do a proper test myself. Regarding extensive use of func_detail and maintaining fast compile times I do agree though. None of my Source maps takes more than 5 mins to compile.
ReNo Posted December 14, 2006 Report Posted December 14, 2006 I'd make the sidewalk a func_detail personally as I'm a sucker for a neat BSP (or maybe leave it as is and use a hint plane across the "dip" in the road), but the performance benefits of cutting down on just a handful of vis leaves is not significant. I've often spent a fair bit of time neating up BSPs just to compile them and find performance is within 1 or 2 fps of the original version. Does make lovely fast compile times for VIS though Of course, if your BSP is complete mess of oddly angled leaves then I'm sure performance could suffer, but by leaving a few brushes as world brushes and thereby creating a few superfluous leaves, you are unlikely to be doing much, if any, harm to your performance.
Wesley Tack Posted December 15, 2006 Author Report Posted December 15, 2006 My latest compile (visleaf) took 3 seconds? as you see in the log I posted it was 4 at that time, is this possible? It's a big map though? Or do you mean for the whole compile to end it shouldn't take more than 5 min? Cause mine at full HDR at normal takes 1 hour 28 mins to compile. And my streets are basically how hessi posted it in his preview, I have an underneath "layout" with the street/sidewalks on top as func_detail, with those as func_detail the cuts in the bsp are a lot cleaner since I have some turns in the road/sidewalk. I'm also a sucker for a clean bsp (I check a lot in glview)
Recommended Posts