Unscrupulous questions

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
1. If more polygons means greater workload, what is the cost to clipping brushes? Is it more optimized to cut one brush into eight in order to put nodraw on one of the faces than it is to leave it one polygon?
2. if I have a texture on a face that isn't touching a visleaf and isn't used anywhere else in my map, will it still be loaded into memory by the client?
3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?
4. How does lots of visleaves affect performance? Does func_viscluster merge leaves?
5. Why does func_detail exist when there is func_brush? Is it cheaper to render?
6. Is a polygon more expensive than a smaller polygon with the same texture and resolution?

And now of a more sinister nature...

1. There is no gravity in the void, but what if the map is leaked?
2. The 2D skybox isn't drawn in the void, but what if a map is leaked?
3. Is it possible to force tonemaps in the void when a map is leaked?
4. Is there a limit of how far the player can move in the void?
 
Last edited:

fubarFX

The "raw" in "nodraw"
aa
Jun 1, 2009
1,720
1,978
1 the fewer brushes, the best. if you think you can save a lot of lightmap data tho, go for it.
2 not sure what planes get discarded by the compiling process. you're better nodraw them to make sure.
3 lower lightmap have higher resolution. higher resolution will have a higher toll on your videoram (I believe)
4 as far as I can tell, lots of visleaves won't affect in game performances but will make your compile a lot longer. from my understanding of it func_viscluster does not merge visleaves. it's used only to speed up compiles.

1 don't leak
2 don't leak
3 don't leak
4 don't let the player into the void
 

Geal

L4: Comfortable Member
Aug 16, 2009
162
56
1. If more polygons means greater workload, what is the cost to clipping brushes? Is it more optimized to cut one brush into eight in order to put nodraw on one of the faces than it is to leave it one polygon?

If it's just one face I probably wouldn't worry about it. Go look at a Valve map and you'll see there are often quite a few brushes that extend out of visible areas that aren't nodrawn. Not a lot, but they're definitely there.

2. if I have a texture on a face that isn't touching a visleaf and isn't used anywhere else in my map, will it still be loaded into memory by the client?

By not touching a visleaf, do you mean it's completely outside the map, as in facing the void? if that's the case I'd assume you'd nodraw it, but otherwise I'm fairly sure VVIS calculates entire brushes, rather than specific textures on them, sooo.... yes? I'm not 100% sure though.

3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?


I'm fairly sure lightmap scale just determines how good your shadows look. A good rule of thumb is that if something looks better, it takes up more processing power.

4. How does lots of visleaves affect performance? Does func_viscluster merge leaves?


More visleaves means more accurate hiding of objects, but it also means the computer is taking more time to figure out what should or should not be drawn - and will increase your compile time by HOURS. Of course, for there to be so many visleaves that it would slow down performance, I would imagine that it would take WEEKS of compile time - AKA you could never make THAT MANY unless you really tried. Generally you want to reduce the number of visleaves in an area, but leave in the ones that really matter. This is done by knowing how VVIS thinks, how visleafs work, and designing your map to be able to be easily optimized. func_viscluster does NOT reduce the number of visleaves, it only tells VVIS that all the ones it covers can see each other, thus speeding up compile time.

1. There is no gravity in the void, but what if the map is leaked?


I'm fairly sure there's always gravity, even in the void. The game knows which way is down, and will always pull you in that direction.

2. The 2D skybox isn't drawn in the void, but what if a map is leaked?


The 2D skybox is ONLY drawn onto the skybox texture. If you can visibly see the void (aka, the map has a leak) then it will either appear black, or will stream or stretch anything that appears in it. Kinda hard to explain, but you'll definitely notice it.

3. Is it possible to force tonemaps in the void when a map is leaked?

I dunno, but since the void is always the same soul-devouring color, I would say no.

4. Is there a limit of how far the player can move in the void?

The void is infinite. If a player falls in, they'll just fall until they kill themselves.
 
Last edited:

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
1 don't leak
2 don't leak
3 don't leak
4 don't let the player into the void

I agree with 'don't carve', but it would be exciting to have a map in the void. Like, a map set in outer space, where a toolsskybox shaft would be so pedestrian. You'd be able to say "THIS IS THE VOID, BITCHES", which is as chilling as the setting.

Also, fewer brushes, good tip. But it doesn't hurt to have lots of brushes "internally", as in, two brushes for every wall, right?
 

Geal

L4: Comfortable Member
Aug 16, 2009
162
56
Don't. Leak.

For any reason.

At all.

edit: well I guess unless you're just testing, but never leak in any actual release.

Also, fewer brushes, good tip. But it doesn't hurt to have lots of brushes "internally", as in, two brushes for every wall, right?

Generally no, so long as you don't have like ten brushes for every wall or something. Generally it's a good idea to have two to four brushes for a wall so you can change textures and include doors and windows. Just makes sure the inside faces that aren't visible are nodrawn.
 
Last edited:

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?

I'm fairly sure lightmap scale just determines how good your shadows look. A good rule of thumb is that if something looks better, it takes up more processing power.
I figured there'd be a difference because most shadows are compiled rather than dynamically generated, and I read somewhere that disabling light filters doesn't help your fps. Am I thinking of something completely different?

2. The 2D skybox isn't drawn in the void, but what if a map is leaked?


The 2D skybox is ONLY drawn onto the skybox texture. If you can visibly see the void (aka, the map has a leak) then it will either appear black, or will stream or stretch anything that appears in it. Kinda hard to explain, but you'll definitely notice it.

As far as I know, this isn't true. If the skybox texture is currently being rendered (which would be always in a leaked map), you can see the sky through nodraw, closed areaportals and world geometry if you clip through them in spec-cam.
 

fubarFX

The "raw" in "nodraw"
aa
Jun 1, 2009
1,720
1,978
I agree with 'don't carve', but it would be exciting to have a map in the void. Like, a map set in outer space, where a toolsskybox shaft would be so pedestrian. You'd be able to say "THIS IS THE VOID, BITCHES", which is as chilling as the setting.

Also, fewer brushes, good tip. But it doesn't hurt to have lots of brushes "internally", as in, two brushes for every wall, right?

heretic! leaks are not exciting...
some walls requires you to have up to 3 brushes per wall. you might have noticed some wall textures with a texture for the bottom, one for the middle and an other for the top part of the wall. only way to get the 3 textures on the same wall is to cut your wall in 3 parts. there's noting wrong with doing so.
 

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
Also, one other thing: In what kind of circumstances does skip work? If you apply it to one face of a world brush, does it make the brush nonsolid like with a glass window or is the skip texture visible? And is it possible to make one-way shooting walls with skip and blockbullets?
 

Ezekel

L11: Posh Member
Dec 16, 2008
818
245
1. If more polygons means greater workload, what is the cost to clipping brushes? Is it more optimized to cut one brush into eight in order to put nodraw on one of the faces than it is to leave it one polygon?
2. if I have a texture on a face that isn't touching a visleaf and isn't used anywhere else in my map, will it still be loaded into memory by the client?
3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?
4. How does lots of visleaves affect performance? Does func_viscluster merge leaves?
5. Why does func_detail exist when there is func_brush? Is it cheaper to render?
6. Is a polygon more expensive than a smaller polygon with the same texture and resolution?

And now of a more sinister nature...

1. There is no gravity in the void, but what if the map is leaked?
2. The 2D skybox isn't drawn in the void, but what if a map is leaked?
3. Is it possible to force tonemaps in the void when a map is leaked?
4. Is there a limit of how far the player can move in the void?


ok. here we go:
if you have a world brush that is touching another world brush. the parts that touch - that part of the face will be discarded on compile. ergo, you don't need to worry about nodraw'ing areas that are partially or wholly covered.
the same is true for faces that are outside of the map (e.g. void-facing faces). that people nodraw these is for ease of use (i.e. for looking at your work in hammer more easily since you can make nodraw faces invisible in hammer).
however: if the brush is a brush entity (func_detail, func_brush, func_door, etc), then faces touching won't get discarded, since these things do not block visibility.

if you have a texture on a face that is wholly covered, or outside the map, then on compile that face will be discarded, thus if that is the only occurence of the texture on your map, it will not be loaded into memory or anything when the map is run.

a smaller light scale will affect performance but shouldn't really be a major affect (i believe it only affects map load times.).

visleaves have a major effect on performance. they work by giving the game something to work with in terms of what can be seen by the player and thus what to render on the screen.
this isn't a realtime event, and the calculations of what can and cannot be seen from any point on the map is worked out in vvis.exe during compile. -ergo 1 thousand visleaves have the same impact as 100 visleaves on performance (that's purely from the "numbe rof visleaves" point of view. of course more visible visleafs = slower, and visleaves with more stuff in them = slower)
viscluster doesn't actually do anything exactly beyond let you the mapper help the compile process along by telling it some of the information it needs (i.e. what visleaves have line of sight).

func_detail renders differently to func_brush since a func_brush is a dynamic entity (it has the ability to do things during runtime), whilst a func_detail is a static entity (it can't change during runtime).

a larger polygon with the same texture would be more expensive to render than a smaller version of it. - it has more geometry to it. drawing the texture upon it would have the same expense though as on a smaller polygon.

as for your questions regarding the void and leaks. i suggest you read up on exactly why you need to seal your world from the void, and why letting things into it is a bad thing. (if you really wanna play around with that kinda thing though, unreal lets you compile a map properly and let players fall into void ad infinitum.)
and note: the void doesn't lack in gravity in source. gravity (direction) is hardcoded. it's magnitude can be altered though (just look for a low-grav server).
in fact in a compiled map, with no leaks, the void is 100% solid. which is why if you noclip into it and turn off noclip you should get a "cannot find world" error in the console (i.e. the game can't find any non-solid area near to you to put you on/in)
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Hurk. So much misinformation mixed into this thread... I'm just going to answer everything straight from the top. So some of this may be repeated.

1. If more polygons means greater workload, what is the cost to clipping brushes? Is it more optimized to cut one brush into eight in order to put nodraw on one of the faces than it is to leave it one polygon?
This depends on what you are doing. If you simply slice one brush into several, the compile will merge the faces back together and split them according to how the compile wants. If you slice them and make a "hole" in the middle that you nodraw, because, say, you have a pillar on a floor, that will result in more faces but the lighting will look better if it's a func_detail pillar. (see the 'eliminating excess' part of this for why this is good) If the pillar is a world brush, it doesn't matter anyway because if world brushes touch the slice each other by default.

2. if I have a texture on a face that isn't touching a visleaf and isn't used anywhere else in my map, will it still be loaded into memory by the client?
All of the following situations will have the faces removed during compile and they will not exist:
Touching the void.
Two world brushes touching each other.
Two brushes touching each other that are part of the SAME entity.

Two brushes touching each other that are in DIFFERENT entities will not be affected. (except for shadows, but that's another subject)

3. A smaller lightmap scale means longer compile and bigger filesize, but does it also affect performance?
The larger amount of lightmap data that needs to be loaded into memory will affect performance. However, it is negligible when compared to the amount of data for all the other textures. Lightmaps aren't something to worry about as far as run-time performance, but it's always good to use as big of a scale as you can without making bad shading.

4. How does lots of visleaves affect performance? Does func_viscluster merge leaves?
Again, the affect on performance will be negligible. The func_viscluster does not merge them, but effectively tells VVIS that all leaves touching the cluster can be considered as one when building the visibility table. You should rarely use these, as it means any time you see a leaf that was touching the cluster, ALL leaves touching the cluster will be rendered (and conversely, if you are IN a leaf of the cluster, all leaves that can be seen from ANYWHERE in the cluster will be rendered). The only purpose of this entity is to cut down on compile time, and it will never improve in-game performance.

A good example of where to use them can be seen if you look at the badwater VMF. There are visclusters up in the sky above the playerclip. The player cannot ever enter the cluster, and there is absolutely nothing to render in the cluster's leaves. Therefore it will have no negative impact during runtime but it will speed up the compile by not having to calculate visibility for a bunch of empty leaves.

5. Why does func_detail exist when there is func_brush? Is it cheaper to render?
An extremely common misconception is that func_detail is an entity. It is not. They are a special type of world brush that is classed as detail. When VBSP is building the BSP, any func_detail have their entity info discarded and the brush is placed into the detail lump (a bsp file has many 'lumps' that store different types of data). For all intents and purposes they work exactly the same as a world brush with two exceptions: because they aren't in the world lump they won't used when VBSP creates the leaves (and thus are not seen by VVIS), and they won't split or cull faces.
Again, not an entity. Except in Hammer because it was the easiest way to mark detail brushes. (as opposed to coding a whole separate detail brush interface)

On the other hand, func_brush is an entity like any other, and can be disabled, enabled, killed, color changed, parented, and any number of things you may wish to do with a brush.

6. Is a polygon more expensive than a smaller polygon with the same texture and resolution?
Honestly I don't know. This is deeper into the engine mechanics than I've looked, and may even depend on the hardware being used.


1. There is no gravity in the void, but what if the map is leaked?

There is always gravity, you are just stuck in place.

2. The 2D skybox isn't drawn in the void, but what if a map is leaked?
The skybox is always drawn at the bottom layer if a toolsskybox brush is being rendered. You can have an enormous hole in your wall that peers into the void, but if you have even a 1x1x1 cube of toolsskybox being rendered there will not be a hall of mirrors, but the skybox instead.

3. Is it possible to force tonemaps in the void when a map is leaked?
Yes and no. If you are experiencing hall-of-mirrors void, a tonemap won't do much of anything. If you have what I said above with the skybox the tonemap should work as usual.

4. Is there a limit of how far the player can move in the void?
Yes and no again. You can move infinitely in any direction but once you move beyond the maximum bounds everything pretty much stops working/existing. i.e. if you make a door near the edge of the grid, and have it extend out beyond the edge and attempt to walk out on it the moment you cross the edge you will fall through because it doesn't exist anymore.

I agree with 'don't carve', but it would be exciting to have a map in the void. Like, a map set in outer space, where a toolsskybox shaft would be so pedestrian. You'd be able to say "THIS IS THE VOID, BITCHES", which is as chilling as the setting.
I can't believe I'm saying this, but carving is actually better than having a leak. If you have a leak then VBSP cannot create the leaves/portals, which means VVIS can't run (which means the ENTIRE map will be rendered at all times), and without vis data VRAD can only do direct-cast lighting and your shadows will be 100% black and in general everything will look horrible.

Also, fewer brushes, good tip. But it doesn't hurt to have lots of brushes "internally", as in, two brushes for every wall, right?
They'll be merged. Unless you have different textures on them. But as I said near the top, the inside touching faces won't exist regardless.

Also, one other thing: In what kind of circumstances does skip work? If you apply it to one face of a world brush, does it make the brush nonsolid like with a glass window or is the skip texture visible? And is it possible to make one-way shooting walls with skip and blockbullets?
Skip should NEVER be applied to any brush other than by itself or with hint. Brushes have "contents" determined by the materials applied to them, and there are several mixtures that cannot go together, usually when you are using tool brushes. Using skip with something other than hint will usually result in an unbounded volume error (because the one side of the brush "doesn't exist") which ends up with the same issues as a leak... VBSP doesn't know what is inside and outside.

To make something one-way you would have to use a displacement, which only have collisions on the visible side.


and lastly, to fubar... skip faces do almost nothing. They do actually have some affect on a map, and I've been meaning to right an article about their peculiarities.
 

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
Excellent. That's all the answers I need.
 

UGLYdumpling

L3: Member
May 24, 2010
127
56
New member here, plugging away on my first room ... ran into a curious phenomenon and this thread seemed like a good place to ask.

This model i copy/pasted out of 2fort ... simply because after going through the static model library in hammer manually, I couldn't find it.

Under the 'world model' property it's listed as (different). Why? And would using it as is present issues on release?

Forgive my ignorance and hopefully I didn't hijack this thread - seemed like a 'random question' topic.

differentv.jpg
 

PL-7764

L6: Sharp Member
Aug 4, 2009
376
84
Selentic is correct. The silver box behind the computer face is one model, and the computer itself is another. Search for "Computer" in the model browser and you'll find them both, plus all the other computer face pieces that can go into that silver box.
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Yeah, notice the title bar of the properties window says "multiple objects" meaning you've selected a group. Use the "Objects" section mode button to select individual objects within the group, or hit the :ungroup: button to ungroup them.
 

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
Another question! Is there any functional reason that people put the trigger texture on their brush entities and areaportal on areaportals (I know the deal with func_occluder) other than convenience?
 

Nutomic

L11: Posh Member
Feb 7, 2009
888
177
As far as i know, it doesnt matter to the engine/hammer, what texture you have on your brush entities, its only so you can recognize easier what it is.
 

Bad Vlad

L2: Junior Member
May 23, 2010
71
16
Don't worry, I once spent half an hour wondering why my brush entities would "disappear" because I didn't know there were three selection modes. Never trust the ignore groups tool.