Proper mapping techniques
Quote from volt on December 1, 2007, 1:58 pmI 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?
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?
Quote from Korjagun on December 1, 2007, 2:06 pmIt 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.
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.
Quote from Duffers on December 1, 2007, 2:18 pmI'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'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.
Quote from volt on December 1, 2007, 2:22 pmWell, 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.
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.
Quote from youme on December 1, 2007, 2:23 pmwhat 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
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
Quote from DaMaGepy on December 1, 2007, 4:42 pmDuffedwaffe 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.zipIgnore 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
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
Quote from volt on December 1, 2007, 4:51 pmThese 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?
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?
Quote from youme on December 1, 2007, 5:00 pmLonger 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 lastBigger 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
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
Quote from MrTwoVideoCards on December 1, 2007, 5:46 pmHaving 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.
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.
Quote from DaMaGepy on December 1, 2007, 6:15 pmI 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..
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..