I don't have very much mapping experience. That said, how "clean" should a map be?

Is it okay to have brushes textured on all faces instead of nodraw on the sides that the player has no chance of seeing? How much of a difference does it make, if any?

It sort of depends. It's certainly good form to nodraw surfaces that the player can't see, but I'm not sure if it's necessary for surfaces that are on the outside of the map, such as the backs of outer walls. I think VBSP may automatically remove those anyway.

I'd recommend laying down all the walls as NoDraw textures, then applying regular textures where needed. Saves a lot of time finding every single edge that you don't see.

Well, an idea I had when I started making the level, is to make everything with a single texture (basic modular floor texture) then change any walls that will eventually be non-portable with another single texture (metal wall).

Then when I was ready to make it pretty I would change any of my nonportable walls to better textures (inlcluding the blocks sticking out, etc etc) then do texture replacement to replace any modular floor with nodraw, then texture everything nodraw.

But I might get lazy and not want to do that last step.

what I do is use the developer textures

make everything useing orange and grey then when you come to texture it once the puzzle works select a load of brushes and swap them to nodraw then select the faces you can see and set them to the right texture

Duffedwaffe wrote:
I'd recommend laying down all the walls as NoDraw textures, then applying regular textures where needed. Saves a lot of time finding every single edge that you don't see.

I nodraw every side that overlaps or the player cant see. I turn on texture application tol, nodraw, turning on the opton to hide faces with nodraw (like noclipping in the compiled map, no yellow nodraw is visible, they are just ninvisible), moving mouse o the 3d view while appication tool still active, pressing Z (to enter movement mode) then I just fly around moving into blocks, circling around the map and hiding faces with rightclicking. if I accidentally nodraw something then I just ctrl+Z.
Check my map01's source, it barely have any face that not visible and there is no nodraw on it, also used some hint texture:

http://heroes.hardwired.hu/-/portal/por ... source.zip

Ignore the missing textures (they are embedded into the bsp)

I always start making blocks with the destination txtures. Then Im not using the block tool anymore, I just copy blocks and resize/apply texture with shift-dragging.
when copying/creating entities, I always use the 3d window (left clicking there) so it places the new entti at the crosshair.
I also creating groups and when there are much room, making visgroups.
Only making func_details at the end.
I use 3d wiev to move around and to select thing a lot.
Also onstantly using alt+enter for properties and [ ] to change grid. All the time.

Basically thats my maping style

These are all good techniques, I especially like what Gepy mentioned with the right-clicking, I didn't know you could do that.

But, I guess I should have made it more clear in my first post in this thread, that I'm more interested in knowing how much of a difference it makes from having surfaces nodraw that should be, vs. not having any nodraw surfaces on the world brushes.

Longer compile times?
Bigger map size?
Longer load time for the player?
More processing power required?

I assume all of the above is true, but exactly how much worse is it? I mean, is it night and day or barely noticeable?

Longer compile times?

turn VVIS and VRAD off untill you need them, that reduces compile times.
when you get near the end of your map and you need to start optimising there are multiple tutorials scattered around, use oen of those (func_details are great for reducing VVIS time and boosting performance, along with hint brushes and area portals)
Only turn VRAD on once you have optimised the VIS stuff, you are just wasting time otherwise.
Always do lighting last

Bigger map size?

you mean filesize or expanciveness? bigger filesize is at your own discression, don't go too large tho. (I don't know a good size limit off the top of my head but most portal maps will be way, way under)
as for map expanciveness - go for as big as is needed, don't feel that you have to make it small if you need a big open space - but then again, portal doesn't need big open spaces.

Longer load time for the player?

carefull balanceing act. Too many quick loads is bad. Only a few huge loads is bad too. You have to get a compromise of medium load time with a reasonable number of loads (this is assuming you are making multiple maps into one game)

More processing power required?

You're joking right? We ALWAYS need more processing power! But what you've got is fine I'm sure

Having nodraw on each side of a brush is unnecessary, as well as nodraw hardly even effects Portal, due to theres hardly any skybox scenery, nor distances that the player cant travel towards.

Also, compile tools, as well as the engine format automatically draws the faces of brushes that touch the void with nodraw, even if they arent like that within Hammer.

And youme's idea is totally dumb, turning off VRAD and VVIS is okay, but not really worth all your time. You're better off keeping all these on to fully test out your map, as not only lighting and vis leafing can help your map extremely out. Or even cripple it. So its wise to leave this on no matter what.

On another not, hinting is very smart, i would suggest using GLView to see how leafs are created within your map, and to fix anything bad. Of Course, Func_detail anything thats needed, apply hint brushes, with only the hinting sides proper in every doorway, opening etc.

Why each opening into another area? Because this smartly draws each area much more efficiently in the engine, and can render all areas much more nicely on fps impact.

Also a list of things to use, which im sure many of you have no idea of theese:

sv_cheats 1
mat_wireframe 0/1- draws everything.
mat_wireframe 2- draws props and brushes.
mat_wireframe 3- draws brush faces.
mat_leafvis 0/1 - draw current leafs, if theres alot in every step you take, then your mapping sucks, alot.
**+Showbudget ** -shows exactly what the engine is rendering all at certain times, and whats hurting your fps the most!

Use all these and you'll be fine. Not to leave out areaportals either, however you'll never have to use Occluders within Portal, those are hardly needed. Also i advise you guys all take a look at this:

http://developer.valvesoftware.com/wiki/Controlling_Geometry_Visibility_and_Compile_Times

This up here is about a solid two hours of reading, but worth all the time.

Another thing to mention is to have the grid as large as possible, why? well thats the basic size of all textures, and brushwork, keeping to this size at all times will help alot when having lots of brushwork. Also the grid is your friend, align to it. And last, there are two lines within the grid in hammer. Orange, and Blue They cut a visLeaf every 1024 units, no matter whats in the way, so make sure that you cut your geometry there to help out the leaf process, and be sure not to have anything complex overlapping those lines.

I always compile with all 3 (bsp, vis, rad) on, on normal. I need to know if lights are ok and for that I also need the map without leaks for extra reflections). vis makes faces nodraw automatically if they otside the map but if for example two block have overlaping sides, vis cant detect that, so they will stay textured usually. Also it speeds up compiling, my maps compile about 6-7x faster after I change everthing unneeded) to nodraw.
Also when I testing the map I use visgroups for rooms, and a separator visgroup, that is a block hat blocks corridors etc with a huge wall, so I can hide for example room 1,2 and the separator visgroup also hae a playerstart and a trigger that initializes everything. So ifI want to test room 3 I just move the playerstart to room3 (priority on playerstart), activating separatot visgroup, hiding room1,2. if I do full compile, I just check all visgroup except separator.
I also have keybindings: N turns clip on/of, , / . = leafvis, b / m = mat_wireframe, u - reloadmap, i - buildcubemaps.
in hammer, I have a custom compule settigs with bspzip automaticaly embeding textures and such plus copies the map, and a batch file that copies the bsp + graph ain and zips it withthe other files (bns) so I can upload the .zip project instantly
Running portal in wndowed mode, compiling, then hitting U to reload level, I buildcubemap, N for noclip and I stat testing... if I ind an error I alt+tab to the editor, fixing then tabbing back..

Nodraw every brush face that can't be seen. if it doesnt have a nodraw, then its gonna get drawn. I dont believe vbsp gets rid of the extra faces, and will draw them.

I remember being told when I started to nodraw everything that isnt seen because it increases compile time and ... well what gepy said (I just read his post as I typed this)

I build everything with nodraw, then texture everything visible. my compile times are nill.

Interitus wrote:
I dont believe vbsp gets rid of the extra faces, and will draw them.

Not true. For world geometry, the compiler will take any face outside the map and any face flat between brushes and remove them, which is why if you have no leaks when you clip outside the map, you can see back in.

Detail brushes on the other hand definitely definitely need nodraw on all faces the player can't see, because they are within the world and the engine will render them.

A lot of good information here, and here are my reactions:

volt wrote:
Longer load time for the player?

youme wrote:
carefull balanceing act. Too many quick loads is bad. Only a few huge loads is bad too. You have to get a compromise of medium load time with a reasonable number of loads (this is assuming you are making multiple maps into one game)

I meant loading a single map, from the time they select which map to load until the time that they start playing.

youme wrote:
func_details are great for reducing VVIS time and boosting performance

Does this infer that any single face not touching the void should be a func_detail? If not, why not? what exactly does func_detailing something do?

MrTwoVideoCards wrote:
Another thing to mention is to have the grid as large as possible, why? well thats the basic size of all textures, and brushwork, keeping to this size at all times will help alot when having lots of brushwork. Also the grid is your friend, align to it.

Does this mean, as I expect, that if you rotate an entire map by 5 degrees for any reason, it will totally ruin just about everything?

Thanks! Also I'm sure this thread is helping many more than just me...

making a brush a func_detail means that VVIS will ignore it. Its helpful for things like windows or the trim around a door. If VVIS were to try and cut visleaves out of it it would make a horrible mess and have way too many leaves (the areas you can see) but if you func_detail them then VVIS ignores them as though they weren't there.
do not go OTT with func details, its not really a sensible thing to do. Also It is worth noting that func_details allow leaks through them.

I suspect that rotating a whole map through 5 degrees will cause VVIS to have a fit - don't try it

A rule of thumb for func_detail is that anything that does not block LOS to another significant area of a map should be detail. What counts as a significant area is a little muddy, and is up to the mapper really. A wall separating two massive rooms with tons of stuff should not be detail, even if it's not expressly touching the void. On the other hand, if that same wall had a bunch of windows, it wouldn't be doing the vis tree a whole lot of good, and therefore the entire wall should be detail.

volt wrote:
Does this infer that any single face not touching the void should be a func_detail? If not, why not? what exactly does func_detailing something do?

Not quite. Internal walls, etc. should not be made into func_details, as they help block line-of-sight to entities, which means less work for the engine. Take this example:

If the wall to the right of the player was a func_detail, all the entities beyond it would be visible to the engine, and therefore rendered, despite the fact you can't physically see them from that point.

Good things to func_detail are small, or oddly shaped brushes, that touch larger brushes. An example is a simple box room, with a cylindrical column stretching from floor to ceiling.

If the cylinder is a standard brush, the compiler will chop up the floor and ceiling where the cylinder touches it. Not only this, but it will chop it up into many oddly shaped pieces, which will affect both compile times and performance in-game, not to mention lighting.

If, however, the cylinder is made into a func_detail, the floor and ceiling will not be butchered by the compiler, and will remain as one brush, instead of 20 odd shaped triangles.

The func_detail method is not limited to complex shapes either. If you have a basic room, and put a small cube brush in the centre of the room touching the floor, the compiler will divide the floor up in a tic-tac-toe style pattern, making 9 brushes instead of one. Func_detail will avoid this.

An example of this usage is the metal walls in Portal, that have panels slightly sticking out in some places to prevent a repetative look. If they weren't func_detail, the walls would end up being split into lots of smaller pieces where the panels touched them, and player framerates would take a hit, as well as compile times being much longer.

To learn more about optimisation methods, go to this site. It is very detailed, if a little hard to follow at times. I only know the basics myself, but even some optimisation is better than none at all

thanks for clearing all of that up!

/restarts map from scratch :p

I've skimmed this thread and seen a lot of "I thinks" and "maybes" about stuff, especially when it comes to optimization. I'd deffinately give this article a read:

http://www.student.ru.nl/rvanhoorn/optimization.php

It explains when and how to func_detail, how the best way to apply hints are, and a lot of other good topics.

All of that said, the best way to learn to get better at making maps that run smoothly and do not have big lag spikes is to learn to think like the compile tools do. When you can learn how the engine works, you can play into it's strengths and weaknesses.

Pretty much everything MrTwo said - especially about staying on the grid - is all true and his link is another priceless read.

I read every word. Made me start my map over, I'll tell you that much!

Yeah it sucks doing that, but in the long run you and your maps will be better off because of it.