I'm somewhat new to mapping so bear with me.
When I am compiling my map I usually have to wait 1-2mins for it to compile and then load the map
I have gone through the compile log and I have no clue as to what is causing this
[url]https://docs.google.com/document/d/1jMSmOTYdICFt0E8uuo9CpLwkhTjVvJ73YrHd_aLSaJA/edit?usp=sharing[/url] (compile log)
If anyone has an idea please help. Thankyou in advance
it could be you just need to optimise your map more :)
[QUOTE=taz0;50906275]it could be you just need to optimise your map more :)[/QUOTE]
The map literally only contains 4 buildings a bridge atm plus a few sidewalks
[QUOTE=AGoose;50906306]The map literally only contains 4 buildings a bridge atm plus a few sidewalks[/QUOTE]
According to the compile log, the lion's share of the time is spent in vvis.exe. You may only have 4 buildings, but perhaps you are constructing them in a way that is really inefficient for vvis to deal with?
For example, there was an Empiresmod map that took [i]a whole week[/i] for vvis.exe to process. The reason for that, was that every building on the map had indented windows, and the outer brushes were not handled as func_detail like they should have been. After fixing that, vvis spent mere [i]minutes[/i] on that same map, with all the same geometry.
This is not to say that you should func_detail [i]everything[/i]. That would be a really bad idea. Only do it to brushes that have no significant impact in blocking visibility.
[QUOTE]he map literally only contains 4 buildings a bridge atm plus a few sidewalks [/QUOTE] even thou you maybe think its a small map when the map is being compiled the build tools work out which brushes can see each other and if the player can see them, i.e if your in a building te game engine might still draw te outside world if you don't tell it not too by optimising the map and its the visiblity calc's vvis does that takes time, here a like link on optimising [url]http://www.wikihow.com/Optimize-a-Map-in-Hammer-Editor[/url] but there are more imformed ones on te web i.e [url]http://www.nodraw.net/2009/12/optimization-in-source-a-practical-demonstration/[/url]
EDIT: Nevermind.. It has decided to rear its ugly head once again. So I will post a screenshot of what I think is the cause
When i remove the highlighted the load time is fine. But when I try compiling it with the highlighted added into the map it causes the compile time to be ages.
Yes I have every non visible bit NoDrawn and the highlighted bit is 1 whole func detail so idk why its causing such long load time
[IMG]https://i.gyazo.com/d28593797eec8200d7649dab2330e64c.png[/IMG]
try making it a displacement, move the func_detail back to a world brush, copy the brushes for later, select each face and make them a displacement, then with the copied brushes make all faces nodraw and place it 1 unit lower than the displacement to seal the map then compile :)
[QUOTE=taz0;50906913]try making it a displacement, move the func_detail back to a world brush, copy the brushes for later, select each face and make them a displacement, then with the copied brushes make all faces nodraw and place it 1 unit lower than the displacement to seal the map then compile :)[/QUOTE]
This sounds like a horrible idea.
The solution to this problem has always been appropriate func_detail usage. But how do you know when it's appropriate? To answer that, you need to know how visleafs are generated.
As part of the Binary Space Partitioning (BSP) scheme that Source uses, the entire map must be divided into convex shapes. These shapes are call leaves, because they are the endpoints of the BSP tree. Introducing complex geometry into an area will cause the compile tools to create a LOT of extra leaves, and vvis needs to do its calculations for all of them, even if the entire affected area has the same visibility to everywhere else. To allow for complex geometry and NOT create a bunch of unnecessary leaves, valve created the func_detail entity, which causes its member brushes to be ignored during the BSP slicing process, and then merged back into worldspawn.
It's a little difficult to make out elevations in your screenshot, but if that area with the benches is higher than the road, then it would make sense to have 1 large "road" brush under the whole thing, and make the visible ground a func_detail. The visibility blocking of the large brush will be effectively the same, but the area will be less complex in terms of BSP slicing, and so vvis will take less time.
[QUOTE=Jcw87;50909200]This sounds like a horrible idea.
The solution to this problem has always been appropriate func_detail usage. But how do you know when it's appropriate? To answer that, you need to know how visleafs are generated.
As part of the Binary Space Partitioning (BSP) scheme that Source uses, the entire map must be divided into convex shapes. These shapes are call leaves, because they are the endpoints of the BSP tree. Introducing complex geometry into an area will cause the compile tools to create a LOT of extra leaves, and vvis needs to do its calculations for all of them, even if the entire affected area has the same visibility to everywhere else. To allow for complex geometry and NOT create a bunch of unnecessary leaves, valve created the func_detail entity, which causes its member brushes to be ignored during the BSP slicing process, and then merged back into worldspawn.
It's a little difficult to make out elevations in your screenshot, but if that area with the benches is higher than the road, then it would make sense to have 1 large "road" brush under the whole thing, and make the visible ground a func_detail. The visibility blocking of the large brush will be effectively the same, but the area will be less complex in terms of BSP slicing, and so vvis will take less time.[/QUOTE]
I loaded up the Portal file and found massive 'clumps' of blue lines and just func_detailed the cause of those lines and now I have cut my compile time down significantly. Thankyou so much for the help
Sorry, you need to Log In to post a reply to this thread.
