Noob Question
#17813 posted by ranhcase on 2016/12/20 03:05:26
probably a stupid question, but is there a unselect button??
#17814 posted by muk on 2016/12/20 03:12:39
In TrenchBroom 2? Esc to unselect
#17815 posted by ranhcase on 2016/12/20 03:15:21
thanks!!!
Leaks: Are these a big deal? should I be aiming to have no leaks in a level? can I just copy paste and rotate non-player area detail stuff and not worry too much? are leaks mostly a problem in places where the player can actually go?
HexenMapper Re: Leaks
Leaks are pretty bad. You don't want them ever. Your map must be sealed much like a water-tight container.
more here: http://www.quake-1.com/wc16a-tutorial/speed.html
Hexenmapper
#17818 posted by NewHouse on 2016/12/20 08:36:32
Don't worry, there should be pointfile after compiling your map. When you open your map, typo "pointfile" to your console and after that "developer 1" (1 = on / 0 = off). Then you should see White lines bouncing somewhere in your map. Try locate area where that Line goes ovet your map's intented boundaries and try figure out how to avoid it no go through for example some corners, maybe light is too near some possible leak area etc. Others correct me if I am wrong, but that is how I can visualize it (don't know about technical terminology)
#17819 posted by PRITCHARD on 2016/12/20 13:41:04
Some (I know TB2 does, I don't have experience with any others) editors allow you to visualize map leaks in-editor, which is nice since you can fix it while looking at it, decreasing iteration time. Otherwise, what NewHouse said is fine.
With modern computers, speeds in Quake levels are rarely an issue. But not everyone has a modern computer, and some people enjoy being able to play Quake on their older PCs regardless of whether or not they have a "better" machine available, so it's important to avoid leaks or poor sealing.
I'm not sure if it's actually worse than just having a straight-up leak in your level or not, but one thing that people sometimes do to avoid having to seal leaks is to encase their entire map in a giant cube of skybox. This is a very bad idea; yes, you can run .vis on your map, but it will take much, much longer, and besides that, you're still not addressing the root issue, which could end up having significant effects regardless of whether or not your map is "sealed".
Func_train And Pathcorner Entity Placement
#17820 posted by Naitelveni on 2016/12/20 22:27:02
How do i know how to align my pathcorner entities? At the moment im using trial and error to correctly place my path corners, its time consuming!
Path_corner
#17821 posted by madfox on 2016/12/20 22:42:29
Knowing the orientation of East in Quark it takes the right lower angle.
Weird
#17822 posted by mfx on 2016/12/20 22:50:40
I could swear the path_corner must be at the lower left corner of the bbox on your pic Maddox.
Madfox
#17823 posted by Naitelveni on 2016/12/20 23:02:48
Thanks!
Mfx
#17824 posted by madfox on 2016/12/21 00:21:47
In that (sensitive) case my east lies downwards.
Whats the best way to split a brush? I've used the C tool and sometimes it splits a brush, other times it chops part of the brush off. What do I need to do in order to consistently split the brush?
Thanks
Entlighted Rogues
#17826 posted by madfox on 2016/12/21 00:46:43
when extracting corners the path_corner stays the same!
@-naitelveni: there's a nice trick you can use to enlighten your windows with this func_train.
Use a window as func_train, and add one path_corner some units before it. Give it the same target and targetname, and wait -1.
When starting the game the window has hardly chance to settle and will turn forward.
If you place a light just before it the front will light up, but as it is replaced now it looks as if the light comes from behind.
A little light before the wall will give it a small shine.
editor
map
screeny
Hexenmapper
#17827 posted by topher on 2016/12/21 00:49:05
it's in the help document
help->Shaping Brushes->Clipping->Clipping Modes
HexenMapper
#17828 posted by Mugwump on 2016/12/21 00:52:12
Check this post by Pritchard for a better understanding of the clipping tool: http://www.celephais.net/board/view_thread.php?id=60908&start=2389
Overlapping Brushes And Leaks
Thanks topher, I should have checked that help file out, very handy.
I'm wondering about overlapping brushes - do they "plug leaks" say if I copy and past a bunch of brushes and rotate them so they're all intersecting, then drag a sky brush down to their top most point (and say they intersect with the floor brush) would these overlapping brushes cause a leak? are overlapping brushes generally considered a no-no?
#17830 posted by topher on 2016/12/21 01:10:06
ah...
i don't know yet.
and put a screenshot i didn't understand either ,
i will ask the last question as well.
are overlapping brushes generally considered a no-no?
i think that overlapping brushed don't cause leaks, because leaks are holes. i don't know if they affect the lights.
i'm just cutting brushes, resizing them, merging them, etc,, for now.
Brush
#17831 posted by mjb on 2016/12/21 01:16:56
You can overlap brushes, some things benefit more from being clean cut but do not be concerned so much with that. Just be aware of z-fighting with textures.
Clipping is the best way to split a brush in TB. You can press CTRL+ENTER to cycle clip modes.
#17832 posted by skacky on 2016/12/21 01:18:33
Leaks are caused by either an exposure to the void or an entity with its origin in the void.
Overlapping brushes aren't very good practice, mostly because of Z-fighting and increased compile time. It's better if you can avoid it. Doesn't really matter if they're made func_detail though since these are ignored during compile.
Overlapping brushes aren't very good practice, mostly because of Z-fighting
Doesn't z-fighting only happen with moving brushes (doors & plats) that move to the same coordinates as other brushes? Surely the compiled .bsp doesn't "know" if two world brushes have their faces on the same plane, because what texture is displayed gets resolved during the compile process.
Sorry, my terminology is probably all wrong, but hopefully you know what I mean...
#17834 posted by muk on 2016/12/21 02:02:48
Go place two brush inside one another, each with a different texture. Compile it, run it in game, and report back to us with your findings.
I've done it countless times with no ill results.
From a post by necros from 2010 (http://www.celephais.net/board/view_thread.php?id=4&start=10212&end=10212):
i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.
i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference.
(emphasis mine)
#17836 posted by muk on 2016/12/21 02:15:03
Now go do it in Hammer/Source ;)
Its just a bad habit that you wouldnt want to carry into other game engines.
AD_Azad
#17837 posted by Qmaster on 2016/12/21 02:56:05
Had overlapping brushes for the pillar lights at the end hanging from the ceiling. Other than that it was an excellent map. *nit pick* *nit pick*
|