Shadow Monkey
Super Monkey
- Jun 7, 2008
- 244
- 23
Wow, awesome thank you so much =)
[TIP] Leaks, Hints and Areaportals
- Thread starter spaceweasels
- Start date
Pretty good qucik guide for noobs.
However I think part 2 is slightly misleading/confusing.
1-You say it's better to have one large vis-leafs. Obviously that's not the case, but after that you start to explain why it's best to have a large one in that room with columns. That all makes sense, but the first sentance almost seems like you mean the entire level should be one leaf.
I think just clarifying that better would help. That it's better to have a fewer large leafs in an area than multitudes of tiny leafs.
2-The next sentance says you will use a hint brush to fix it, but then you skip right to func_details.
You should probably change the hint sentance to func_details to fix. Because then you change the cylinders to func_details.
3- towards the end you say having alot of small leafs can be fixed by hints. In actuality hints would make it worse, I think you are just having hints/func_detail confusion.
probably just got sidetracked in that tut section.
So I'd recommend pulling all hint stuff out, place it after the explanation of func_dteail in it's own area.
The true reason for hints is 'to make more leafs' so you can minimize views where Hammer fails to.
Also, when you get around to telling how to make a hint you say to use a 1 unit wide brush. While that works it will create 2 extra leafs. One 1 unit wide inside the hint brush, and the new one you used the hint to create.
You should drag 4 of those verts together in the 'skip' side and you'll have a pyramid hint brush. That'll only make one cut and one new leaf per hint.
However I think part 2 is slightly misleading/confusing.
1-You say it's better to have one large vis-leafs. Obviously that's not the case, but after that you start to explain why it's best to have a large one in that room with columns. That all makes sense, but the first sentance almost seems like you mean the entire level should be one leaf.
I think just clarifying that better would help. That it's better to have a fewer large leafs in an area than multitudes of tiny leafs.
2-The next sentance says you will use a hint brush to fix it, but then you skip right to func_details.
You should probably change the hint sentance to func_details to fix. Because then you change the cylinders to func_details.
3- towards the end you say having alot of small leafs can be fixed by hints. In actuality hints would make it worse, I think you are just having hints/func_detail confusion.
probably just got sidetracked in that tut section.
So I'd recommend pulling all hint stuff out, place it after the explanation of func_dteail in it's own area.
The true reason for hints is 'to make more leafs' so you can minimize views where Hammer fails to.
Also, when you get around to telling how to make a hint you say to use a 1 unit wide brush. While that works it will create 2 extra leafs. One 1 unit wide inside the hint brush, and the new one you used the hint to create.
You should drag 4 of those verts together in the 'skip' side and you'll have a pyramid hint brush. That'll only make one cut and one new leaf per hint.
Last edited:
GrimGriz
L10: Glamorous Member
- Jan 2, 2009
- 774
- 133
I could use some more info on the HINT and SKIP brushes. How do they work? Are you hiding stuff (like the cylinders) behind the HINT brush so that VIS doesn't take too much time processing it? What does VIS do when it encounters a HINT? What's the difference between a HINT and a SKIP.
On the plus side, I'm a lot less confused than I was before I opened the thread
On the plus side, I'm a lot less confused than I was before I opened the thread
I have a question about this amazing tutorial.
I, being a complete noob at Hammer, have decided to make a second map. So I set about making a rather good looking map (once I decided to pay attention to the details). Well, when it came time to compile, it didn't even compile. So I looked up some optimization techniques and I got it to compile after I changed most of the non-main walls into func_details. But it is still taking like 30 minutes to compile.
Would it make a big difference to place areaportals on every doorway and door?
Also, I just thought of this: if you turned ALL your brushes into func_details, and then made a huge brush box around your entire map (including around the skybox) would this be efficient? (Don't be too harsh on me if you think this was the dumbest question ever)
Thanks a bunch!
I, being a complete noob at Hammer, have decided to make a second map. So I set about making a rather good looking map (once I decided to pay attention to the details). Well, when it came time to compile, it didn't even compile. So I looked up some optimization techniques and I got it to compile after I changed most of the non-main walls into func_details. But it is still taking like 30 minutes to compile.
Would it make a big difference to place areaportals on every doorway and door?
Also, I just thought of this: if you turned ALL your brushes into func_details, and then made a huge brush box around your entire map (including around the skybox) would this be efficient? (Don't be too harsh on me if you think this was the dumbest question ever)
Thanks a bunch!
30 minutes seems like a quick compile to me. I've not known areaportals to decrease compile times, they a more for dictating ingame rendering. But it would be wise to place them in most doorways for the sakes of ingame optmisation anyway.
Your hint brushes will also help with the ingame rendering but also majorly effect your compile time (if used correctly) in a positive manner, as it shows vis how to properly work out how your map should be rendered (IE less data to be written to your bsp as viewer places are seeing other places) with an efficient compile due to appropriately placed hints.
Turning everything into func_brush or any solid entity for that matter will be disasterous. For starters solid entities do not block vis, and thus line of sight. Everything would exist in one huge visleaf and therefor be rendered at once, you would probably crash your system if you tried to open and play it. Solid geometry (standard brush work) blocks vis and line of sight and therefor provides cover from visuals in other sections of your map. You want to make sure as little as possible is rendered at anyone time and this means physically blocking line of sight to other area's.
edit: If you tried to understand the mathematics involved in the process rather than the effects of the process you would probably have been able to answer your own questions. It would probably be worthwhile reading a more advanced tutorial on hints/skips and areaportals over at VDC or perhaps interlopers. These a more mini tutorials to help you utilise the basic tools rather than understand the bigger picture.
Your hint brushes will also help with the ingame rendering but also majorly effect your compile time (if used correctly) in a positive manner, as it shows vis how to properly work out how your map should be rendered (IE less data to be written to your bsp as viewer places are seeing other places) with an efficient compile due to appropriately placed hints.
Turning everything into func_brush or any solid entity for that matter will be disasterous. For starters solid entities do not block vis, and thus line of sight. Everything would exist in one huge visleaf and therefor be rendered at once, you would probably crash your system if you tried to open and play it. Solid geometry (standard brush work) blocks vis and line of sight and therefor provides cover from visuals in other sections of your map. You want to make sure as little as possible is rendered at anyone time and this means physically blocking line of sight to other area's.
edit: If you tried to understand the mathematics involved in the process rather than the effects of the process you would probably have been able to answer your own questions. It would probably be worthwhile reading a more advanced tutorial on hints/skips and areaportals over at VDC or perhaps interlopers. These a more mini tutorials to help you utilise the basic tools rather than understand the bigger picture.
Last edited:
Hey thanks! I'm glad to know that 30 minutes is a quick compile time (phew). How long do your maps take to compile usually? (Just to compare) Thanks!