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.

Skotty wrote:
What exactly needs this long time? VRAD, VVIS oder VBSP?

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.

Skotty wrote:
Just post your last compile log. You can find it in the same directory where your vmf ist. It's named like your map with the ending .log.

Is this what you meant?

The amount of characters were too big for the post.

Ald?z wrote:
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. =[

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.

Ald?z wrote:
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.

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.

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.

Vis compile time will increase noticeable with single big rooms. If you have a lot of small ones connected with small hallways it won't need very long. Thats because in the big room it needs to create a lot of big Visleafs.
So if you create maps with outside areas, try to use func_viscluster.

A normal compile time in Portal 2 should be max. 2 Minutes for Vis.

Lostprophetpunk wrote:
I didn't know about optimization until now. I shall work on the optimization of my next map, but the first map will take me ages to optimize as I'm still learning how to do it.

Glad I could help. Optimization is such a huge topic you can easily drown in it. Portal is rather forgiving though, since it's mostly small rooms. You'll get far with the basics, like func_detail. Then there's hint brushes, areaportals, areaportal windows, func_visclusters, nodraw, lightmap grid resolution...

Skotty wrote:
[...]
Vis compile time will increase noticeable with single big rooms. If you have a lot of small ones connected with small hallways it won't need very long. Thats because in the big room it needs to create a lot of big Visleafs.
[..]

Just to clarify; size doesn't matter in itself. The exposure and number of visleaves does.

Skotty wrote:
Optimization of existing maps is difficult. The start of every map should already be optimized.

So would I need to make the walls for the rooms into a func_detail? I am still reading up on area portals and all that.

The function of func_detail is simple: small brush details or pillars can be func detail.
Every brush will "cut" the Visleafs into more. If you have chambers in destroyed theme and place broken tiles out of brushes everywhere, maybe with different rotations, each of them will cut the visleafs into more. Just think: Vis compile time will decrease with less visleafs.
If you hide all func_details, a room should look as simple as possible. That means: no details (broken panels etc.) and flat surfaces.

skotty wrote:
Optimization of existing maps is difficult. The start of every map should already be optimized.

I thought about that for a minute. There isn't much to optimize in the beginning. I prefer to optimize in the end of the creation process because I make so many changes that any optimization soon becomes obsolete.

Ald?z wrote:
Anything that's significant for blocking visibility and sealing the map should not be func_detail.

So from what I am reading, the walls can be world brushes, but anything inside a func_detail. As all of my walls/floors seal the map, so no leaks happen.

Then at the start of an entrance to another room, I should place an areaportal?

Use func_details just on details, small things and pillars. If you have a wall blocking the whole view of the player, don't make it to func_detail, because the VIS will hide everything the player can't see behind this wall.
If you make walls in your room to func_detail, the game will render all objects behind the wall while the player can't see them (and thats waste of FPS). Always think like this!
Small details on the floor like single broken tiles won't block the players view, so make them to func_details.
Small pillars in a room won't block the view, because you can look past it.