First Map Check

Bud Calypso

L1: Registered
Jul 28, 2015
39
25
I know it's just another variation of Orange. But by rebuilding it from scratch I've learned
about Hammer in the last days. So please ignore the rebuilt layout.

I'm looking for someone who is willing to take the time and have a look at the .vmf or .bsp.
I need to know what I am missing to make a map work properly.

I did go through the map checklist provided by EnglishMobster on this site
and only excluded the cubemaps for me, see reasons below.
And I did check the compile-log by interlopers but couldn't imagine
what is to take seriously or can be ignored.

Things missing I'm aware of but don't understand yet properly:

Packing
Cubemaps
optimized visleaves
HDR compile
ControlPoint Resapwn Adjustment

+optimized texturing


This being said, the map works for me if I run it - without problems mentioned yet.

I don't ask anyone to teach me everything. I just need to know what are essential mistakes I made or did miss completely.
If anyone has the energy helping me out in detail, it would be appreciated but I don't expect that.

I'm also new to dropbox, so I hope the Link works :)
https://www.dropbox.com/sh/tmlmeu893yc8eiy/AACUfjdCl8Hp1533e6tGJKD8a?dl=0

Thx in advance,
Bud
 
Last edited:

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
- No area portals on doorways
- The roof and front wall of your spawn rooms are func_detail. This means they don't block visibility. It's not a great issue here because your walls are quite high and the map is quite simple. But making them world brushes would separate the inside and outside spaces, helping ensure that players inside the rooms are much less likely to render things they can't see. You can move things to world brushes by selecting them and clicking Tools > Move To World (Ctrl+Shift+W).
- The invisible texture cuts visleaves. Use clip when you want to stop players but allow projectiles. If you want to stop projectiles, and you have A Boojum Snark's pack installed, use Block Bullets as his version doesn't cut vis.
- The map uses func_wall. This is a deprecated entity that is replaced by func_brush. These brushes can be turned on and off and have their solidity changed, but in your map they have no logic to them telling them to do so. They are glass brushes. You can just make them world brushes and they won't cut vis. Or func_detail if you prefer. It doesn't matter in such a small map but when you make larger stuff there might come a time when you need to keep the number of 'edicts' down - those are entities that the server has a state in memory for, and dynamic brush entities like func_brush each take up one.
- Your map is composed of lots of large brush faces. Some of the faces have very simple shadows on them and so you can reduce their lightmap scale from 16 to something like 64, 128 and 256. This will save space in the BSP but can make shadows look blotchy in some places. To combat that, you can chop up brushes and leave the parts that have shadow on them as 16.

Side note: You don't have to nodraw the faces of world brushes and func_detail that share an edge with, and are completely cover by an adjacent world brush. Those faces will automatically be culled when the map is compiled. For example, most of the unseen faces of your ramps. The same effect happens on faces that are fully out in the void. (Note that a world brush face that shares an edge with a func_detail face and is covered by it will not be culled. So nodrawing those world brush faces that are obscured by func_detail is good practice).

I did some of the stuff I'm telling you about as an example. I didn't put any areaportals on the central building because it's not actually to the grid so I can't draw the areaportals correctly. I know you didn't make this map, but when you work to a sensible grid size like 16 and 32, it helps down the road. Don't go sub-16 unless you are working on small details.

There is no team_round_timer entity in the map so rounds can go on forever. Also, there is no entity saying what should happen when the server time ends. If you want the map to finish when the server time ends, use a logic_auto sending an output to tf_gamerules, and the input SetStalemateOnTimelimit with a parameter of 1.

Screenies

188XZHb.png


1 - These security fences have their collision type set to vphysics. Vphysics collision should be used when a prop is going to be walked on by a player. They are also set too far forwards so a player standing by the wall who was blasted upwards could get caught on one of them. You should pull them back a bit and make their collision type bounding box. Even better, make them non-solid and draw a Block Bullets brush over them to save collision data in the BSP. It's not much but it's a good habit to get in to. The same goes for props in your resupply rooms. They won't be interacted with so don't need vphysics. Note that using the bounding box is fine when a prop is rotated parallel with the grid lines. If it's rotated diagonally its bounding box will increase in size so watch out for weird collisions. The bounding box is visible in Hammer when you select the prop.

X7Fs7tm.jpg


2. - Your orange building is all func_detail yet players can get inside and its openings cut cut vis and prevent things in and outside from being rendered. Make it all world brushes and put area portals in the windows and doors.

q33uvbW.jpg


3. - Doing a VBSP-only compile generates visleaves. Loading the portal file showed me these visleaves. You have two sets of world brush walls in your map that share a common height. If you put a hint-faced brush along the top edge that covers the whole map you can shape the visleaves so that players behind the walls are less likely to see what's on the other side.

tBithqx.jpg


Fin.

EDIT: Look up information about visibility optimisation on the Source SDK wiki and do a search for web pages and YouTube videos. There are a lot.

EDIT EDIT: I forgot to link you to the modified VMF. Don't go ahead and use this, use it to see what I did in conjunction with what I typed. http://wurmz.net/stuff/temp/OrangeC.zip
 

Bud Calypso

L1: Registered
Jul 28, 2015
39
25
Wow, first up thx for taking the time and the effort!

I watched a ton of tutorials with 20 tabs adding additional info and understanding
to the engine and the logic behind the tools of hammer.
But as mentioned, some topics I just don't get the hang of it.

- Modifying visleaves effectively is still a miracle to my brain.
As far as I understand it:
Numportals are sections which create a "room" that renders everything visible by the faces of that "room" to the next numportal, originated by the player's position.
Everything else won't be rendered as it is visibility-blocked for the player anyways by world-brushes, who define the numportals following this logic automatically.
But let's take the most common example used in the how-to's and tutorials for the usage of func_detail, the cylinder.
One bigger than viewheight does block visibilty for the player to the opposite side of the cylinder,
yet it contains no visleaves after making it an entity and is a recommended example. I don't get it..
I made the frontbrush of the spawnroom and the roof a func_detail because it was recommended to do so with roofs and walls with windows. But if you say it is more likely for players inside to spare the rendering of what they can't see outside by leaving it a world_brush - I get a bit more confused.
The visleaf that comes with that worldbrush would seperate 2 "render-rooms".
And by this the more visleaves, the better.. ? Sure, I still misunderstand this.

- I tried Clip, Player-Clip and Invisible Texture, coming from: https://developer.valvesoftware.com/wiki/Tool_textures; All Stopped projectiles for me, so I thought it doesn't matter which
But I didn't watch out for the visleaf-cut. Will change that.

- it must have been an older tutorial i chose for making glass-brushes. So I just have to apply the glass texture to a brush or func_detail and it will work the same?! ok

- I tried to use as least brushes as possible, so big ones are intentional. Doesn't cutting them for texture purposes create more visleaves and faces? I know about scaling the lightmap, but not enough to generaly make sense of it's usage. Does it balance the additional faces and visleaves or am I wrong in the first place again?

to the sidenote: Good tip, but no-drawing what gets culled anyways, may be unneccessary but ain't wrong either, I guess..

I actually made every brush of the map and added what isn't in orange_x3. The goal was to make it less sniper-friendly by changing as least as possible. (by this I just started getting insight to the world of mappers)
The tower isn't on grid because I started with it and stretched it once, when I didn't know the consequences.
The reason I got used working with grid-size 1 lies in the remake. Recreating the preferrably exact dimensions of the original orange_x3 gave me a lot of additional work, I regret now. I didn't have any sample .vmf and just wanted to start.

- I have seen many basic tutorials who end up without logic_auto. I stumbled up on it before,
but didn't know if neccesarily needed. I wondered how to set up roundtime, now I know!

1. -> I made the fence this forward because I tested to jump on it and it worked this way.
Being able to change to the bounding box as barrier, is useful to know. Will making a prop non-solid mean that projectiles would go through and players too, I guess?! Will try out.
Btw: orange_x3 has cut off fence-props at the borders of the map. I couldn't figure out how to do/hide that.

2. Hard for me to understand again what gets rendered when and why it is good to change back to more visleaves by worldbrushes.. And as I didn't get the basic idea, I didn't get farther than func_detail and kept area portals and (3.) hints as the rest of visleaf-optimization to be done when understood..


There will be the day that my brain will befriend with these visleaves. Not today though.

But this and what I mentioned myself in the intro aside, I'm happy it would generally work.
I've teached myself basic Blender-modelling recently and had some adobe-premiere / after effects experience, but keep on ignoring that it's about 10% creativity and 90% technical effort.

So thanks for the help again! Now I won't give up too early! :)
 
Last edited:

henke37

aa
Sep 23, 2011
2,075
515
The point of func_detail is that it doesn't block visibility. Instead it saves the effort of computing visibility for something that wouldn't have made a noticeable impact.
 

tyler

aa
Sep 11, 2013
5,102
4,621
For your func_detail/visleaf question, take a look at this: http://www.optimization.interlopers.net/index.php?chapter=func_detail

With that pillar, leaving it world geometry makes a bunch of stupid leaves that all see each other. So the player will be rendering everything around them anyway, and you're just wasting compile time. You want less vis leaves because they create more calculations during compile and, when playing the map, if the client has to calculate the visibility of too many leaves, that can cause slowdowns. However, it's pretty hard to do that. In the case of this pillar, there's no reason at all that the area around it should be split into separate leaves. The same with the window trim, stairs, etc. Try going into Valve maps and toggling func_detail with r_drawfuncdetail 0 to get an idea of what is made f_d. Note that some things which would normally be problematic may just be hinted instead for whatever reason but there's usually a good reason to do that.

So in the case of the pillar, whether it is func_detail or not makes no difference to the player--but it does for you when compiling. Of course, the more detail geometry like that you make, the more you func_detail to save yourself hours of compiling.

For clipping, just use playerclip or clip. Playerclip is better; clip has different functions in other Source games and I'm forever afraid they'll do something similar in TF2 and break all the maps using clip. (Probably won't happen, but still.) If you want to block bullets/projectiles, use blockbullets. Whoever said Snark's version doesn't cut vvis is right, but his version isn't compiled into the map--he did a sneaky thing to trick Hammer into seeing one texture and compiling another. So in most cases you also want to func_detail those as there's rarely a reason they need to cut vvis.

Glass brushes (and anything transparent, like chicken wire or metal grates) won't cut vvis ever. You can make them and leave them alone.

Using the least brushes possible isn't that important unless your map is 3 stages, the size of Hydro, or some other kind of weird outlier. VBSP combines faces anyway, and smaller brushes (I rarely go above 512x for ground brushes, and brushes in buildings are smaller too, like 384x max typically) are easier to work with. Try to stay on a grid size of 16u at least when blocking out alphas. You'll likely change things later; keep it easy on yourself.

Everyone has a different philosophy for nodraw. Some people block out their whole maps with it; to me, that leads to visible nodraw in the map. I'd rather texture things as little as possible. Any face completely touching the void or completely covered is culled anyway; it's easier imo to go in and nodraw things the player won't see manually, and runs less risk of weird visibility bugs cropping up.

To get back to func_detail and vis leaves, you want more leaves in your map because they separate areas the player renders. Mangy's tutorial is pretty good about discussing that I think, if the Interlopers one was hard. Optimization is a balancing act that is difficult to get down, and part of optimization is simply in creating a good layout that lends itself to easy optimization. Basically, more leaves are better because it divides the level into smaller chunks, so players render less at once, but lots of tiny stupid leaves like around the pillar don't really help anyone.

Let us know if you have other questions.
 

Bud Calypso

L1: Registered
Jul 28, 2015
39
25
The Interloper's Guides could actually speak my language on this topic, as your remarks did.
I won't have much time within the next days to get conclusions out of it, but I will afterwards.
More questions tba too, If I get stuck on research myself.
Thanks for the quick and caring support so far!
 

tyler

aa
Sep 11, 2013
5,102
4,621
The best thing to do is probably to not worry that much about getting it perfect right off the bat, because most people don't bother optimizing with hints and occluders until beta stages or even RC. Just try making some maps and you'll start to learn through experience what works and what doesn't.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
People tell you to make cylinders func_detail because they don't like the splintering visleaves that come off them. But if your cylinder is quite large and does actually block sight, then you can leave it as a world brush. It doesn't matter if it makes a few more, as long as you don't have loads of them pointlessly (though you can actually make it func_detail and hide a square nodraw world brush inside it to block visibility. That creates nice square visleaves and blocks vis to a certain extent. Very clever). If you have a small brush that will never block sight, then there is no point in it creating visleaves. Though sometimes it's helpful to leave brushes as sold when they are touching the other world brushes because they can cull the faces behind them and have nicer shading.

If you have more visleaves in an area then the area is split up in to more and smaller sections, meaning that if you approach it from an angle, you are likely to have less rendered. You can check what's being drawn by the game using the console command mat_wireframe 3.

Clip and Player Clip don't block projectiles unless they are made part of func_detail. Typically, it is unnecessary to make a tool brush a func_detail. Indeed you can use whichever tool texture you like, there are pros and cons to each.

When you make at least one face of a brush a transparent texture then the engine no longer lets it cut visleaves because logically it can be seen through. So yes, either a world brush or func_detail are fine. There is an advantage to making a brush a dynamic entity like a func_brush - stickies will not stick to them and you cannot spray on them. But that should be done in special circumstances.

If you take a large brush and clip it in two, it still occupies the same space but increases the number of faces. It shouldn't cut any more visleaves. The only times world brushes cut more leaves is when they are used on the edges of buildings. But even if they did create a new portal or two, it's cost benefit. The brush faces here are so large that it would really benefit to reduce lightmap scale on faces with low shadow detail because it saves more file space. An extra visleaf won't affect performance. In such a large and simple map, the lightmap savings outweigh the cost to visleaves and number of faces. A lightmap is basically a texture of the shadow that you see on a brush face. Increasing the resolution gives finer shadow detail, creasing it gives lower shadow resolution and softer shadows. This can be used to your advantage to soften shadows across a brush face sometimes. But the lightmap scales are changed when you either need to have that sharp shadow detail or when the brush face doesn't benefit from any shading. A brush face in exposed sunlight with no other brushes or props around it won't have any shadows at all, and so you can jack that right up to something high. The less lightmaps you have in your map and the smaller their resolution, the more space you save. Typically this kind of optimisation is done for fully textured maps because it's more of a polishing thing. But I talked about it here because you have large faces and could benefit, and it's a good thing to learn.

tyler already said half of what I said but I typed this out without reading the thread. Sorry, ty. I've just been a bit preoccupied. I learned the ffects of visibility optimisation from TopHattWaffle's YouTube videos. They're great.

I actually find optimisation really fun.
 

tyler

aa
Sep 11, 2013
5,102
4,621
Lightmaps are cool and useful, but I personally wouldn't bother with them until mid-to-late betas or RCs even. They can reduce filesize by quite a lot, but in early alphas and betas, it's typically not worth doing since you might be changing the layout after testing anyway.
 

Bud Calypso

L1: Registered
Jul 28, 2015
39
25
@tyler
I know I don't have to do it perfect. Noone is waiting for that map, neither am I anymore.
But this remake of orange with some tweaks shall be my sample to learn and train by.
I won't mix optimization and layout too soon, because the layout is set yet.
And it is mandatory to me to understand the mechanics of the engine, hammer and its tools in general
to get an idea of the limits of the playground. Trial and error will be the method to go, true that!

I took a break though from the visleaf-topic before this humiliation of my brainpower scratches
at the self esteem I get by my perfect body. ;)

@worMatty
as soon as I equalize this unbalance, I will be able to better appreciate the input. I learned a lot by
TopHattWaffle too, but not enough in terms of visleaves yet.
Your modified .vmf was and will be a big help. I changed and copied what I thought I understood.
Most of the visleafparts didn't work out my way (areaportals) or didn't want to be adopted by a
stranger. I checked some decompiled valve maps to compare - also to set the game logic correct:

A TeamRoundTimer with OnFinished-outputs to:
gamerules (set stalemeateontimelimt) +
tcp (SetWinner) (->neccessary?)

As well as a logic_auto with an OnMultiNewRound-output to
gammerules (set stalemeateontimelimt)

As far as I understand it, the omnipresent teamfilters are used for doors which of orange does not imply.
So the respectively last ControlPoint of each team fires an OnOwnerChangedtoTeam-output disableing the
enemy's respawnroomvisualizer. Right?! Well, worked.
For more progress, I cubemapped and packed the map.
For someoneone willing to check if this was done correctly:
https://www.dropbox.com/s/s045q2jqq94oz1r/otest3.7z?dl=0
To check for details and logic: https://www.dropbox.com/s/kk18sk3s6m74uxv/otest3.vmf?dl=0

In the last days I joined a lot of events of TF2maps, some may have recognized.
Thanks for having me, it's a lot of fun and a wide variety! Introducing the additional questions:

1. Why are events called imps? :)
2. Why do most testmaps use dev-textures? (state of development or performance?)

3. Is to compile with HDR common or bonus?
4. How does the console effect a .bsp file? (buildcubemaps)
(I always thought console only has ingame influences)

5. How to balance the contrast between shaded and lightened textures?
(I played around a lot with brightness and ambience, but only toning colours down worked for me)
6. Orange_x3 has cut-off/halfway-hidden fence-props on the outskirts of the map. How?
7. How to adjust the amount of rounds a map has?
8. Triggerarea-Respawntime-Adjustments: Do these count only while a team is capping the point?
(the description is a bit confusing to me with "owning" and "capping" otherwise)

I will be out of town and afk till mid/end week, but keep on working on this afterwards.
Hopefully with a light(bulb)-entity over my head, ready to adjust. See ya there!

Thx in advance

Bud
 
Last edited:
Nov 2, 2010
355
1,048
1. 'Imp' is short for 'impromptu', as in a map test that isn't planned beforehand. If enough people have maps ready for testing then they can request an admin to run an impromptu map test on one of the servers. The other map tests are Gamedays which are planned about a week in advance- there's an area in the forum for submitting maps to those.

2. It's better to leave detailing til later in development when the layout and gameplay are acceptable and are unlikely to change significantly. Detailing a map from the start means you might have to delete a lot of your work or shift stuff around with lots of detail on it and mess everything up. It's just easier, really.

3. You really only want to compile with HDR on your final version (the release candidate). There's no point in using HDR for alpha or beta maps because it just takes extra time to compile and it won't really matter when the map's detailing is unfinished anyway.

4. Not entirely sure what you're asking here, but there are some commands which are used to overwrite data about the bsp file, such as building cubemaps or navigation meshes for playing with bots. It's just stuff that can't be done without the engine running.

Kinda busy right now so hopefully someone else will answer the rest of your questions
 

henke37

aa
Sep 23, 2011
2,075
515
Dev textures are used for two reasons. One is to act as a substitute while waiting for the art team to make the textures. The second, and more common one, is to simplify the mapping process. There is no need or even the ability to focus on cosmetic details while you are still figuring out the map layout. Dev textures both tells the players to ignore the visuals and eliminates the need for you to deal with them.
 

tyler

aa
Sep 11, 2013
5,102
4,621
4. I don't really know how to answer this. To my knowledge, building cubemaps is the only process that actually affects the BSP. Navigation meshes need the BSP to be running in game to be made and edited, but they aren't part of the BSP (just to clarify what Corvatile said). I guess the answer is it just does. Be aware that building cubemaps changes the size of the BSP, and you can do it over and over on the same map and bloat the file size. Don't build them unless it's part of a compile.

5. If I understand your question right, it's about lighting? I'm not quite sure what you mean in this regard. Lights have a color/brightness value which looks by default like "255 255 255 200" iirc. The first three are RGB and the fourth is intensity. There're also fields for a 50% and 100% falloff distance if you want to manually tweak how far the light is cast (useful for candles or small lamps or just making an area look more believable/better). It sounds like you played with one or more of these without fully understanding what each one does? The falloff settings don't need to be adjusted in many cases (though, I invariably do adjust them myself, constantly).

Textures can have a reflectivity property (I think most or all of them do except maybe toolsblack off the top of my head?). Some textures in the game are just edits to that value. You can look up materials for more about that, if you're interested, but it likely is not important for you at the moment. You can also color shift things textures--a few of the cp_manor wood textures are "burned" through this method. Handy for reducing file size.

6. It's been forever (6-7 years?) since I've looked at Orange, but it sounds like they selected the fence model and simply dragged it into the brush's bounding box. Tons of models are half buried in things across all maps, especially rocks in displacements. Be aware that the entire model renders if the player can see any of it, so you're not saving them anything by hiding stuff halfway in brushes.

7. I'm not sure I understand this one either... but I wonder if it's because you're asking the question you mean to ask. Usually maps change after a set period of time on the server, whether it's 30 minutes or an hour or something, or it never changes because the time limit isn't set. So if that's what you're after, it's essentially up to the server operator to decide. For instance, on TF2M, we have our default map times for arena set at 10 or 15 minutes (I can't remember exactly) because that lets us get a lot of rounds in on those maps, but something like a CP or PL map will get more time so we can get in more rounds.

If you're asking about multi stage stuff, like on Dustbowl or Goldrush, that's a longer and more complicated answer.

8. Again not sure exactly what this is asking, and again I think it's a reflection of you asking about something you don't yet entirely understand? So it's good you're asking, but I think the question is predicated on a misinterpretation of how capture points work?

When you see an output like "OnCapTeam2" or something, that means when BLU caps the point the output fires. Not as they are capping, but after they've capped. I am not even sure there is an output that can fire when a point is contested--I haven't used one before, but it's probably still possible to detect and act upon.

So, if you see something that is adjusting a respawn time, it happens only after the point is capped, not during. Otherwise chaos would ensue. Probably. Hopefully that answers what you're getting at.

Unfortunately I can't check your work as I'm still on vacation. But, I want to suggest you stop messing around with cp_orange_x. Try using the artpass map instead. It's all dev textures, like orange, but it has working entities that are set up right and very little optimizing. It's also scaled right, so it will inform your education better. You could start by adjusting/detailing/modifying the layout or whatever. It's probably also just built better, frankly, though I've never decompiled orange to look. I feel like that will probably be more useful to you than orange, which is a traditionally stupid map that invades and pervades many multiplayer games.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
Or you could check out any of the many orphaned maps on our site, many of which were left in their dev-textured phase or only partway through detailing.
 

Bud Calypso

L1: Registered
Jul 28, 2015
39
25
Hey again,

thanks for all the detailed answers to these very basic questions.
I prefer to get some eyebrown-lifts and a newbie-reputation
than progressing slower. My gaming background is way older than
looking under its surface.

-> 1.
I joined enough events meanwhile to figure out why they are called
imp(promptu) myself but tend to think initially complicated to things sometimes.

-> 2.
I thought this way before but wasn't quiet sure about the main reasons.
But let's say I do detail a barn with props to some extend and then
shift it to another space. I may lose the time I detailed it, but I
can imagine me prefering to at least texture it because the details
are part of the map's overall impression.
I can also see that this may overlay the focus on gameplay which should
work in the first place.

-> 3.
I haven't looked it up yet, but wonder if there has to be adjusted more than the
additional cubemaps for HDR. (I guess this can be figured out by myself)

-> 4.
This is a good example of my introduction, if I confused you with this question.

-> 5.
What I played around with was Ambient and Brightness.
I felt these relate to each other somehow but didn't get the hang of it.
The more detailed adjustments are likely to understand for my brain,
but I agree with tyler, that these aren't important for me atm, as for this simple map.

->6.
I changed the fence-line so it fits its distance which is the better solution overall.
But it overlapped with the skybox-brush. How to drag into this bounding box and make it non-visible?

->7.
So rounds are defined by the gamemode chosen or limited by timelimit?!
I didn't know that. Maybe there was a way of setting a roundlimit manually - was my thought.

->8.
It was this part of the help-information that inspired me to think complicated (owning/capping):
"If the red team owns this point when blue captures it, this adjustment is reversed."
Thanks for clearing this out @tyler


To follow tyler's suggestion and having it at a point that doesn't miss anything,
I now finalized it and even uploaded it to the workshop to make sure I stop working on it.
http://steamcommunity.com/sharedfiles/filedetails/?id=495634423&searchtext=
It wouldn't accept my .bsp.bz2-file for some reason though. Had to take the .bsp.
Something wrong with it? https://www.dropbox.com/s/ms3xo7uig450zod/cp_orange_x3_fus_b1.bsp.bz2?dl=0


I do have some own ideas to start something custom and new.
I hope you guys kept some patience for me, because there could be more confusing questions coming up. :)

But this will be another thread to come.

Off-topic-question:

I just discovered the tf2maps youtube channel and exceptionally enjoyed it.
It seems abandoned lately. Why did you stop or had to?

Laterz.

Bud
 
Last edited: