Question about submerged faces

Dario D.

Spy
Joined
Nov 30, 2004
Messages
710
Reaction score
0
Do faces submerged in Solid get annihilated during compile? Are those faces still there during gameplay, rendering inside solids?

Example... say you have a street, and you accidently cloned the street, so there's an *extra* street stuck inside the solid brush. Will it be there ingame, or does it get deleted during compile?

Should I worry about faces that are inside brushes? I just spent a few hours turning them into nodraw.
 
Yes. If I am correct, they will be compiled, but you won't be able to see them.

Not sure if this affects in-game speeds, but would almost definately affect compile times
 
Have brushes overlapping will seriously ruin VIS's shit and as a result performance in your map will suck balls.
 
why dont you click on the extra street and press the delete key? this may help if it bothers you
 
Here's another related question. Say i have two brushes touching eachother in such a way that one face on each brush will never be seen, do i have to nodraw those or will it do it automaticaly?
 
POWDERKEG said:
why dont you click on the extra street and press the delete key? this may help if it bothers you

It's not that simple... most of these brushes have at least one useful face, and the others are submerged in solid or just not seen. :O

In most BSP engines (Quake, UT) any face submerged in solid gets deleted, as solids cancel out all other BSP.

I figured Source was no different, because it DOES use BSP... of some sort, right? Why does it leave faces inside solids? Doesnt make sense, unless it's a "func" of some sort, which doesn't subdivide BSP.
 
well, you could test it out. make a map with this issue, load it, and put it into wireframe mode. I'd be interested to hear the results, if you do.
 
FireCrack said:
Here's another related question. Say i have two brushes touching eachother in such a way that one face on each brush will never be seen, do i have to nodraw those or will it do it automaticaly?
get into this habit:
whenever you are going to make a new wall select the nodraw texture before creating it and then apply the directed textures to on the sides that players will see.
 
silentbob said:
get into this habit:
whenever you are going to make a new wall select the nodraw texture before creating it and then apply the directed textures to on the sides that players will see.
Sounds good.
 
Dario D. said:
Example... say you have a street, and you accidently cloned the street, so there's an *extra* street stuck inside the solid brush. Will it be there ingame, or does it get deleted during compile?

No this won't be deleted by compile. This can slow render times by adding unneeded faces as well as look bad, since the engine is trying to draw both on the same plane.

FireCrack said:
Here's another related question. Say i have two brushes touching eachother in such a way that one face on each brush will never be seen, do i have to nodraw those or will it do it automaticaly?

Yes these faces are culled automatically. No need to apply a no_draw texture.
 
No, I didn't mean 2 planes running through each other in the exact same location.

I meant a street brush running "inside" a larger street brush.

Side view:

--------------------------(street brush 1)---------------------
--------------------------(street brush 2)---------------------
--------------------------(street brush 2)---------------------

--------------------------(street brush 1)---------------------

Street brush 2 is inside the solid space of SB1. Will SB2's faces get erased during compile? If not, will they render ingame?

Basically what I want to know is, "what happens to a face that's inside a solid?"

In other engines, anything inside a solid gets deleted during compile and simple doesnt exist anymore.
 
I'm wondering if there are any other rules about when hidden geometry is culled? I was going to make a map with complex brushes, to make organic world shapes, like a detailed cave. If I have a lot of individual brushes, but all the faces meet up precisely, then it shoul all be removed, right? I was thinking about making parts of a level out of four-vertex, four-sided brushes (to avoid issues with invalid convex brush shapes), and then pair them up on the backside with another so the brush group has a solid continuous volume...
That might not be a good explanation. If I think of a better way to explain.... hmmm.


And...
May I say, DM_Plaza17 looks extremely cool. :thumbs:
 
Dario D. said:
No, I didn't mean 2 planes running through each other in the exact same location.

I meant a street brush running "inside" a larger street brush.

Side view:

--------------------------(street brush 1)---------------------
--------------------------(street brush 2)---------------------
--------------------------(street brush 2)---------------------

--------------------------(street brush 1)---------------------

Street brush 2 is inside the solid space of SB1. Will SB2's faces get erased during compile? If not, will they render ingame?

Basically what I want to know is, "what happens to a face that's inside a solid?"

In other engines, anything inside a solid gets deleted during compile and simple doesnt exist anymore.

Not sure why you would want to do that, but I imagine it would be culled. Generally any faces in the void are removed when compiling.
 
Well, I never actually *want* to do that, but sometimes brush faces end up in useless places (like inside or along-side other brushes) and I don't want to spend time searching for them all and nodrawing them...

I was hoping they'd get deleted during compile, like other BSP engines, so that I wouldn't have to worry about them.
-
(btw, thanks Phisionary)
 
I guess I gotta do everything myself :rolleyes: ;)

Check it out:

Image1: hammer editor, flat shading.
Image2: hammer editor, wireframe. Notice--the first (left) box intecepts the floor, the second (right) box contains a third box, which is completely enclosed within the second.
Image3: In-game, regular rendering.
Image4: In-game, rendering w/ wireframe view enabled. Notice-- the geometry spidering cause by intersecting world brushes.
Image5: In-game, rendering w/ wireframe view enabled, closeup on large box. Notice-- no wireframe is visible for the third (completely hidden) box.

[Edit] Note: I should have used a more visible texture. Meh. Also note that I crossed a 1024 line, stupidly, so not of all the 'spidering' is caused by the intersecting brushes.
 
Ok, cool. Thanks for doing that.

I guess there's no need to nodraw EVERYTHING then, except to save lighting compile time.
 
I use this as a general rule when I'm building;
Build the whole map with orange/gray dev textures. When you're done, you just need to replace those textures with nodraw (When you've applied visable surfaces with the texture you want, obivously).
 
Edit: [Deleted stuff] ---Oh, wait. Actually, you're saying to do just about the opposite of this guy. Nevermind. hmmm.---

silentbob said:
get into this habit:
whenever you are going to make a new wall select the nodraw texture before creating it and then apply the directed textures to on the sides that players will see.
Edit2: Personally, I build all my new brushes as nodraw, and texture them later. Unless it's a crate or something, which I'll nodraw once I've finalized placement.
 
Dead-Inside said:
I use this as a general rule when I'm building;
Build the whole map with orange/gray dev textures. When you're done, you just need to replace those textures with nodraw (When you've applied visable surfaces with the texture you want, obivously).
You ARE referring to the "replace" button, right? The one in the right-side panel.
 
Yeh, Dario, that I am. It's also in the Tools menu up top if I'm not mistaken.

It's a lot better to build it like this instead of creating everything with nodraw to start with, because if you compile with nodraw you can't see anything. So you *have* to texture stuff before you complie. With the dev textures you can work on areas, or the whole map, and then texture and change things (Use VisGroups to compile whole or parts of the map, only selected visgroups are compiled). It really gives you an advantage to see the scale of things, and how they line up to eachother.
 
Back
Top