Compiling time?
Heya there,
I have a map which contains two rooms, and there are not large rooms at all. However, when I compile it, it seems to take about half an hour to compile.
Is there anyway to reduce the time it takes to compile? As it's quite annoying when trying to fix bugs and test to see if they have been fixed etc.
|| Need help uploading a map...new user? Read my Map Uploading Guide ||
|| Want to play custom maps, but don't know how? Read my Playing Portal 2 Custom Maps Guide ||
I have no idea.
I am an inexperienced mapper with Hammer. I have got all the settings on normal, and set it just to compile, and not to run after.
|| Need help uploading a map...new user? Read my Map Uploading Guide ||
|| Want to play custom maps, but don't know how? Read my Playing Portal 2 Custom Maps Guide ||
Is this what you meant?
The amount of characters were too big for the post.
|| Need help uploading a map...new user? Read my Map Uploading Guide ||
|| Want to play custom maps, but don't know how? Read my Playing Portal 2 Custom Maps Guide ||
It's vvis that takes most of the time (33 minutes and 48 seconds in the latest log entry). You need to optimize the map. You most likely need to turn world brushes to func_detail. Did a quick search on VDC and found this for more info: http://developer.valvesoftware.com/wiki ... timization.
Thank you for that.
I am a bit confused, as most of my map is fun_detail anyway. I have started to read about visleafs, but they confuse the hell out of me. =[
|| Need help uploading a map...new user? Read my Map Uploading Guide ||
|| Want to play custom maps, but don't know how? Read my Playing Portal 2 Custom Maps Guide ||
fun_detail? 
Maybe that's why it's slow...
A visleaf is an invisible volume that knows which surfaces it touches. If you can "see" into a visleaf, then the game will render the surfaces associated with it (only those facing you).
VVIS calculates which visleaves that can see each other during the compilation. If there are many visleaves, and they can see each other, it will take a lot of time.
There are two things you can do to identify the source of the problem. You can filter out everything except world brushes with the visgroup tool. You can also load the portal file (Map > Load Portal File) to see all the visleaves in the map. Their edges should turn up in blue in the 3D view.
Then you'll be able to identify which brushes that cause visleaves to be created. Brushes that aren't important in blocking visibility (like pillars or wall details) should be made into func_detail. They will then no longer split the world into more visleaves.
Maybe that's why it's slow...
A visleaf is an invisible volume that knows which surfaces it touches. If you can "see" into a visleaf, then the game will render the surfaces associated with it (only those facing you).
VVIS calculates which visleaves that can see each other during the compilation. If there are many visleaves, and they can see each other, it will take a lot of time.
There are two things you can do to identify the source of the problem. You can filter out everything except world brushes with the visgroup tool. You can also load the portal file (Map > Load Portal File) to see all the visleaves in the map. Their edges should turn up in blue in the 3D view.
Then you'll be able to identify which brushes that cause visleaves to be created. Brushes that aren't important in blocking visibility (like pillars or wall details) should be made into func_detail. They will then no longer split the world into more visleaves.
Didn't notice the typo. hehe.
One thing I have found is if I change the compile options to 'fast' for VIS, it takes like 1 minute.
Thank you for explaining visleafs to me. Much appreciated.
|| Need help uploading a map...new user? Read my Map Uploading Guide ||
|| Want to play custom maps, but don't know how? Read my Playing Portal 2 Custom Maps Guide ||
It's not necessary to quote a whole post when your answer is the next post. It clutters the thread imho.
Back on topic:
I don't know exactly what fast mode does, but it's crude (and thus fast obviously). It's good when you want to avoid very low framerates during testing. If your map is relativly small, and it takes about 30 minutes to compile in normal mode, you have a serious optimization problem.