I made a map and I have issues with performance. There are many maps out there that are twice the size of mine and my computer can run them smoothly. My map is not even filled with anything, it's basically just empty space, but I feel like I have half the FPS that I usually have. What influences that? Is there anything I can do about that when compiling the map?

Jimmy wrote:
Hello,

I made a map and I have issues with performance. There are many maps out there that are twice the size of mine and my computer can run them smoothly. My map is not even filled with anything, it's basically just empty space, but I feel like I have half the FPS that I usually have. What influences that? Is there anything I can do about that when compiling the map?

We need a bit more info than "It's a big map but runs worse".

• Do you have large masses of liquids? Many of these cause lag.
• Do you have a dynamic light lighting the big area? The sheer size can cause a significant performance drop.
• VVIS often hates large, open spaces, but in Portal 2 that has been optimized greatly (See: Enrichment Spheres) so unless your area is absolutely HUGE I can't see that being the source of lag.

Can we have a screenshot of the area where it lags the most/ a pic of the entire area so we know how large it is?

1. Tie all brushes that don't seal the map to func_details. If any func_detail (or whatever other func_something or entity) touches the world the compile will return an error, a leak. If this happens just go to map > load pointfile and a red line will be displayed showing you where is the entity that is touching the world.

2. Texture with the nodraw texture all the sides of your brushes that the player won't be able to see. Tipically the first ones are all the external sides of the brushes that seal the map.

3. If you have different separated chambers, I'd suggest that you make a brush at the entry, covering the whole entry from the floor to the ceiling textured with skip texture and then texture the front face of this brush with the hint texture.

That should save quite some compile time and also should make performance smoother. There are still another important optimisation element, the areaportals, but as it's more complex let me know if you already increased performance after doing the above...

And:

Quote:
2. Texture with the nodraw texture all the sides of your brushes that the player won't be able to see. Tipically the first ones are all the external sides of the brushes that seal the map

You don't need to nodraw the external sides. It is done automatically when compiling.
Also, I wouldn't tie all brsuhes which don't seal the map to func_details, only the necessary ones. (Read the guide to learn which the necessary ones are.)

Thanks.

@josepezdj, I'll do that, and yes, mapping in Hammer.

Screens:

http://i.imgur.com/uWFq7.jpg

http://i.imgur.com/vNzpH.jpg

http://i.imgur.com/hTx1f.jpg

As you can see I have only normal lights (since I haven't learned about different ways of lighting a chamber yet). This map is not finished and I don't want to continue it when there are already performance issues that I cannot fix. It's not like I can't walk or anything, but I notice a difference to other maps. The time that it takes to compile this map is not very long.

edit: Oh and thanks Brainstone

If you use "noclip" and go outside your map, can you see the outside walls? If so, then you have a leak somewhere, either an actual hole or one of the props (stairs, walkways etc.) outside the map.
(It's not a problem to have part of a prop sticking through the wall, but its center must be inside the room.)

Brainstone wrote:
To understand how map optimization works and what you as a map creator have to do, read this HL2-guide:
http://www.optimization.interlopers.net/

And:
Quote:

1. Texture with the nodraw texture all the sides of your brushes that the player won't be able to see. Tipically the first ones are all the external sides of the brushes that seal the map

You don't need to nodraw the external sides. It is done automatically when compiling.
Also, I wouldn't tie all brsuhes which don't seal the map to func_details, only the necessary ones. (Read the guide to learn which the necessary ones are.)

Only wanted to say Brainstone that I didn't know about that Optimisation guide (well, I remember I found it by accident some time ago while searching for something, but never ended up there again though), and that one was a really awesome read! I've read it all (all chapters) 2 times and learnt a damn lot, mate! Moreover, it served to me more to settle down my knowledge, to fill certain gaps about some things, and to go in depth with some others... thanks!

HMW wrote:
The only reason for poor performance I can think of here, is that your map already has a leak.

Portal 2 maps will not compile if there is a leak. Leak on VDC.
So the reason is only optimization. And that guide is realy great.

greykarel wrote:
Portal 2 maps will not compile if there is a leak.

I surely wish it wouldn't! That would save many people a lot of problems in the long run.

You are partially right though. If you pass the "-leaktest" parameter to VBSP, it will refuse to compile a leaking map. Sadly, not all of Hammer's preset compile options include that parameter. If you use the "normal" mode, it will happily compile and run a map that has a leak. Some of the "advanced" settings include -leaktest, but not all of them.

greykarel wrote:
And that guide is realy great.

Absolutely. Required reading for any serious mapper.

FelixGriffin wrote:
Really? I just use the defaults and it doesn't make a leaked BSP.

If you switch the compile window to advanced mode, the "default" preset does include -leaktest for vbsp, so that will stop compiling when it discovers a leak. However, (on my configuration at least) the simple / normal mode doesn't do that, and I assume that this is what most novice mappers use.

I don't know whether the OP is a novice mapper, but that is besides my main point, which is: it is possible to get a leaked map to compile and run, and therefore we can't rule it out as the source of the problem.

(However, that being said, at this point I should probably admit that I never compile from within Hammer nowadays, and my statements above are based on a few quick tests, and about my knowledge about that -leaktest option. I would love to be proven wrong about this; it would be very useful to have leaked maps not compile by default, so you know immediately when you have a leak, rather than finding out about it by all of its nasty side effects, when your map is nearly finished.)