It means you need to optimize, give this a read to understand [url]http://www.optimization.interlopers.net/[/url]
_deleted
The materials used in the map are required to be on the compile machine. If they're missing, all faces in the map that use them will be fullbright.
The same goes with static world models, if they're not present, neither the model or world around them will be properly lit.
You also have several "micro brushes" which are brushes less than one unit on any axis. They can be caused by malformed brushes due to carving or vertex manipulation.
Depends on the map and level of optimization.
City 2 takes an entire day if my CPU is running full blast. (About 16-20 hours. Not really that bad, I just start it a couple hours before bed, and then when I wake up, it's done.) But that was before I optimized the balls out of it. Haven't tried to full compile it yet.
I remember one version of City 18 I had took two weeks, and was actually canceled when it was on 9.. (power outage)
City 33 took a bit shorter amount of time than City 2. (It used to take a couple minutes but after adding the outlands it added a couple of hours to the compile time.)
Torrington took a couple days for me aswell.
Haven't really bothered with any other maps.
The most it's ever taken on FINAL is around 3 hours on an unoptimized map.
[QUOTE=antimonycat;46432766]The most it's ever taken on FINAL is around 3 hours on an unoptimized map.[/QUOTE]
RP maps often are very complicated?
The main question aside, what type of map are you compiling?
The man reason for long compile times is the lack of func_details. (Which are ignored by VVIS). If you have complex shapes and anything that IS NOT ESSENTIAL for visibility or sealing the map, then it should be func_detail.
I was making an open, detailed town map and even though I optimized and func_detailed liberally, it took a few days to compile because it was generating too many visleafs due to my layout and placement of buildings. I cut compile time down to a few hours just by making some func_viscluster brushes to cover the entire cordoned area, and performance was still good because of fade distances. Saved my life.
For a release version I would create and place the visclusters strategically to allow rendering of certain areas over others, instead of a single massive brush covering everything or several smaller brushes in a grid.
My longest compile time is Rockford which is is a total of 5 hours on the button.
Final compile without staticproplighting and staticproppolys (as they break and fuck shit up)
[B]VVIS[/B]: 2h 23min
[B]VRAD[/B](LDR): 1h 19min
[B]VRAD[/B](HDR): 1h 18min
I find the easiest way to optimize a map is using the AUTO section of the visgroups box and turning off everything that's not a world brush which cuts visleafs or optimization brush (areaportals, hints, etc) including func_detail so you can actually visualize what brushes are being used to render visleafs, and what brushes you can turn into func_detail. It also helps you to find places to drop hints and areaportals or even occluders.
[QUOTE=Kemerd;46433286]The man reason for long compile times is the lack of func_details. (Which are ignored by VVIS). If you have complex shapes and anything that IS NOT ESSENTIAL for visibility or sealing the map, then it should be func_detail.[/QUOTE]
The main reason for long compile times are excessive numbers of visleaves or large open areas or both.
Func_detailing indiscriminately can make compile times much longer and ingame performance much worse.
Most of the stuff I've worked on takes between 5-15 minutes. I do surf maps though, which is quite different. surf_illumination took 15 minutes to compile, surf_voteforthisone took about 10-12
_deleted
[QUOTE=Kemerd;46433286]RP maps often are very complicated?
The main question aside, what type of map are you compiling?
The man reason for long compile times is the lack of func_details. (Which are ignored by VVIS). If you have complex shapes and anything that IS NOT ESSENTIAL for visibility or sealing the map, then it should be func_detail.[/QUOTE]
Yes the map is complicated with a lot of props. 3 hours isn't all that much though on the [Final] setting and like I said I've only partially optimized.
20 minutes? Guys? What kind of massive map are you using?
[QUOTE=antimonycat;46455004]Yes the map is complicated with a lot of props. 3 hours isn't all that much though on the [Final] setting and like I said I've only partially optimized.[/QUOTE]
Whether a map has 0 props or 2000 props has almost nil effect on compile time. It's all visibility calculations and radiosity.
This map:
[t]http://i.imgur.com/yZyCjzw.jpg[/t]
Has 1,408 props of all types, 319 brush entities and 448 lights.
A normal compile takes about 3 minutes.
A detailed compile with fancy lighting (self shadowing models, alpha masking on transparent textures) and extra bounces takes about 5 minutes.
A detailed compile with HDR takes from 7-10 minutes.
[QUOTE=Statua;46435504]My longest compile time is Rockford which is is a total of 5 hours on the button.
Final compile without staticproplighting and staticproppolys (as they break and fuck shit up)
[B]VVIS[/B]: 2h 23min
[B]VRAD[/B](LDR): 1h 19min
[B]VRAD[/B](HDR): 1h 18min
I find the easiest way to optimize a map is using the AUTO section of the visgroups box and turning off everything that's not a world brush which cuts visleafs or optimization brush (areaportals, hints, etc) including func_detail so you can actually visualize what brushes are being used to render visleafs, and what brushes you can turn into func_detail. It also helps you to find places to drop hints and areaportals or even occluders.[/QUOTE]
VRAD still should've taken the longest time and not VVIS.
In my experience, I had about half an hour spent in total with:
5 to 15 seconds on VBSP
30 seconds to a minute on VVIS
30 minutes total on VRAD with both LDR and HDR, final, textureshadows, staticproppolys, staticproplighting.
It depends on the map you're working on. Open maps will take a lot longer if you don't use visclusters.. Rockford is at the limits of pretty much everything but displacements. If the 30 seconds bsp time didn't clue that in for you then idk what to say lol. Also, after doing a bit of optimization, I reduced vvis down to 10 minutes. vrad is still the same.
I had a map with a TON of small details and weird angles. Out of curiosity I tried a full HDR compile before optimizing. It took ~53 hours.
30 minutes of optimizing and it compiled in full HDR in around 5 minutes. And that was just with making details into func_details
[QUOTE=onebit;46514428]The skybox height can have huge effect on the time.[/QUOTE]
If the skybox is empty, no. If the skybox has things in it like tall buildings, yes.
[QUOTE=GiGaBiTe;46523343]If the skybox is empty, no. If the skybox has things in it like tall buildings, yes.[/QUOTE]
Not quite, vvis still has to calculate visibility way above the map; so anything cutting visleafs on the ground below go all the way up to the top, increasing compile time.
[QUOTE=glitchvid;46524863]Not quite, vvis still has to calculate visibility way above the map; so anything cutting visleafs on the ground below go all the way up to the top, increasing compile time.[/QUOTE]
Uh, no.
VVIS does not calculate visibility from multiple points within a single visleaf, it does it from the center of the visleaf to all other visleaves. It doesn't decide what the ground is and calculate it from there and then calculate it from the sky, it's redundant.
Leaves are created on the X/Y planes and are infinitely high. So if you have an empty skybox, you're going to have single leaves that are 1024x1024 by however tall the skybox is.
[t]http://i.imgur.com/ttgaHqH.jpg[/t]
And your argument of things cutting all the way up to the top is invalid too. It creates a local distortion, but it does not transverse up to the sky.
[t]http://i.imgur.com/Pr6nVIu.jpg[/t]
Whether a room is 256 units tall or 18,000 units tall will take the same time to run visibility calculations on.
[t]http://s.gvid.me/s/2014/11/20/1416471147-0mc.png[/t]
[t]http://s.gvid.me/s/2014/11/20/1416471152-5pc.png[/t]
[t]http://s.gvid.me/s/2014/11/20/1416471289-6Mc.png[/t]
[t]http://s.gvid.me/s/2014/11/20/1416471294-2Uc.png[/t]
Doesn't look that way from here, although I would like this further explained.
* Not my map, simply a base brush version of someone else's for optimization testing.
From VDC:
[quote]Note: Leaves work vertically as well as horizontally. Treat skies as extensions of the streets and rooms beneath them.[/quote]
Just out of curiosity glitchvid, what happens to compile times when you put a func_viscluster in the entire area above the houses?
[QUOTE=Statua;46536292]Just out of curiosity glitchvid, what happens to compile times when you put a func_viscluster in the entire area above the houses?[/QUOTE]
What you expect, it stops it culling all the way to the top of the skybox.
[t]http://s.gvid.me/s/2014/11/20/1416538169-4Gc.png[/t]
[t]http://s.gvid.me/s/2014/11/20/1416538176-43c.png[/t]
It also does a bad job at the optimization, since now it considers a lot of the space around the house to "see" itself; whereas if you lower the skybox it properly cuts.
When the skybox is lowered:
[t]http://s.gvid.me/s/2014/11/20/1416538373-7Hc.png[/t]
[QUOTE=glitchvid;46538472]What you expect, it stops it culling all the way to the top of the skybox.
[t]http://s.gvid.me/s/2014/11/20/1416538169-4Gc.png[/t]
[t]http://s.gvid.me/s/2014/11/20/1416538176-43c.png[/t]
It also does a bad job at the optimization, since now it considers a lot of the space around the house to "see" itself; whereas if you lower the skybox it properly cuts.
When the skybox is lowered:
[t]http://s.gvid.me/s/2014/11/20/1416538373-7Hc.png[/t][/QUOTE]
You need to use a hint brush the same dimensions as the func_viscluster.
But you can see whether the skybox is tall or short, you have roughly the same number of visleaves, they just get extended upwards.
Hints work by faces, not brushes. That's why you should always make your hints using the skip material. If you drop a hint face along the bottom face of the viscluster, will it produce the same effects as having the skybox low or will it not make a difference?
Yes he has the same number of visleafs, however it is making 3 times the amount of calculations which is unnecessary.. Hence the 15 sec compile time.
[QUOTE=glitchvid;46531759]Doesn't look that way from here, although I would like this further explained.[/QUOTE]
As I've had it explained to me by a guy that modified the Valve compile tools, VBSP creates leaves by essentially a large carve operation. So if you notice any similarities between carve results and how visleaves look, you have the answer.
[QUOTE=Statua;46539505]Hints work by faces, not brushes. That's why you should always make your hints using the skip material.[/QUOTE]
In an ideal world where we had non-shit compile tools, then yes that would be fine. In reality, the hint texture has a much lower chop priority than a worldspawn brush and can result in funk if you only texture one face with hint. VBSP loves to ignore hint brushes unless you texture all sides of the brush as hint, and it doesn't matter if you do this as long as you make the hint brush properly.
[QUOTE=Statua;46539505]If you drop a hint face along the bottom face of the viscluster, will it produce the same effects as having the skybox low or will it not make a difference?[/QUOTE]
Assuming the compile tools aren't being :downs: then it will create a cut along the hint face and create new visleaves above inside the func_viscluster. The new visleaves will be treated as one essentially and won't cause problems like above where the house can see into itself from all sides.
The compile time also depends if you got a good CPU.
If you got a single core you're going to have to wait a much longer time.
Sorry, you need to Log In to post a reply to this thread.
