Geometry compiling question. Created 11 years ago2013-02-11 05:14:45 UTC by kraken

1 is the shape I want to achieve but it is invalid.

2 is using ctrl f to make the invalid face valid, and I want to know if this is bad practice opposed to the common terrain and vertex manipulation technique which is to split the shapes to create the triangular faces which is what 3 is.

So what I am wondering when this stacks up what if there are advantages to one approach or the other.

heh, i never know you could use ctrl+f like that for example #2, does it compile ok like that?

Yeah, not sure about the clipping, though.

Is this the object you are trying to achieve?https://dl.dropbox.com/u/54462712/Mapping/SlickedObject.7z

That's kinda combining both 2 and 3 for a more versatile shape. I'm just asking if I only if one approach is better for optimization than the other.

I don't really understand how the compiling process works, I don't even know if it makes a difference.

Then unseen faces are discarded, however, yes, there is some clipping bullshit going on. Don't worry about this shit too much and read Daubster's tetrahedron terrain tut

Oh, thats the question, dunno, you will have to test it

Well after reading that I guess 2 should be better considering less face splitting.

After reading about bevel though I am a bit confused. Wouldn't it be best for optimization to bevel every unseen face on the map? What's the point of nulling unseen faces then?

Look, both of them work. If u use null texture on the sides which the player wont be seeing in-game, you will have the same w_polys in both. The bottom wont be viewed by the player just like the middle split and the sides (I assume u want the top to be viewed only). About VIS, well that is not that much of a difference. But, if u are going to use this in a larger quantity it might affect the compile time a bit, that is for example with 2 brushes, example 3, but the w_poly should stay the same.

1 thing tho, if u are using VHLT compile tools (for hl1/cs1.6... the source tools already have them), all those weird shapes u make, u should convert to func_detail. It is quite an awesome function when it comes to optimizing. But be careful when using it so u dont get a leak.

What about 2D shapes? Has anyone tested that? In terms of wedge vs tetrahedron . Possible clipping disaster?

Well, tetrahedron is messy but does the job very well. I use different techniques for making terrain and complex structures. I might make a tut about it, but dunno when...

Tetrahedrons take too much time, try trimesh:

http://twhl.info/forums.php?thread=18271

Major limitation in comparison to wedge or tetrahedron method.
1 seems to work fine but 2 seems to trigger the coplanar faces error.

That shouldn't trigger the coplanar surfaces error, although it is an invalid brush anyway because it has a concave section.

If the angle is 180 or greater (I.E. concave) It will either produce respectively the coplanar face error or and invalid solid, but hammer won't tell you that.

this would have been a good method to use for 30 brushes as a sculpting tool, but I suppose u could clip to achieve a similar result.

it would be interesting to test what methods produces the least planes, to maximize goldsource's meager limit.

Honestly, engine wise, it doesn't make a difference. Like previously mentioned, you would end up with the same amount of faces whether it was one brush or two brushes. I suppose it'd be easier to handle one brush while mapping, but it be safer to manipulate two brushes so you're not at risk of throwing an invalid brush error.

As for nulling the unseen faces, that doesn't matter either (in my opinion) unless you think they might possibly be seen. If this was going to be a walkable section, you might want to bevel everything except the top faces.

I don't know exactly what bevel does, its been too long since i've used it. But i do remember people saying it was good.
I think i came to the same conclusion as well.. but again.. i don't remember.

/2 cents

I don't understand why you are insisting on using the least amount of brushes possible. All those brush faces are split up into triangles during the compile anyway, and grouping makes it easy enough to treat multiple brushes as one, anyway. You aren't saving wpoly; the only possible result might be a slightly reduced compile time because of slightly less faces for the compiler to null off. Maybe.

Just work with triangles from the beginning, it's so much simpler.

I don't know exactly what bevel does, its been too long since i've used it. But i do remember people saying it was good.

Bevel is like null, but it also causes the face to ignore clip nodes during compile. In other words, the player can walk through a beveled face. It's useful for maps with lots of complex geometry, IIRC.

Bevel was also introduced much later than null, I think.

Edit:Shape #2 shouldn't be made out of one brush in the first place. That's literally one of the first things a mapper learns.
And just for good practice, shape #1 shouldn't be one brush, either. If you insist on not using triangles, you will eventually do this by accident:This will not compile, and you will go insane trying to find the problem.

Edit Edit: To answer your original question, neither is more optimal, but it's safer to just use triangles/wedges/tetrahedrons.

Well it isn't about brush count. It's about convenience. This method can create complex brushes very quickly and can be much much faster than regular multibrush VM techniques.edit: Also to quickly find that problem, check the brush number in the compile log and use the 'go to brush #' soup, very easy to find.

I'm just asking if I only if one approach is better for optimization than the other.

Well it isn't about brush count. It's about convenience.

Don't lie to me.

It's about both. I just know how convenient it is already, and need to know if there are optimization issues that are worth trading off for the convenience.

Well it isn't about brush count. It's about convenience. This method can create complex brushes very quickly and can be much much faster than regular multibrush VM techniques.

but there might be solid brush problems beacuse it should calculate each face you are looking into one solid brush, it is makes sometimes players glitch inside brushes and it is the not only problem

this is the what im trying to do: (fixed into 2 clipped brush)
http://c1302.hizliresim.com/16/l/k7fzz.jpg

if I use one brush this is what happens in game: (otherwise crashes)
http://b1302.hizliresim.com/16/l/k7g0b.jpg

That's the flat/concave problem I just addressed. You could split the face in the opposite direction and it wouldn't bug up but the geometry would be different.

I've been wondering for a while, if you bevel one side of a brush, and normally texture the other side, does that create a one-way brush?
As in you can walk through it one way, but it blocks you if you walk the other way.

I would test myself, but I am currently on a library computer so I can't for now.

BEVEL isn't completely non-solid, it does block bullets, projectiles etc. And you can't walk through as u deeeeeescribed. But its very buggy and sometimes makes the normal texture non-solid. Thats why I dont use it

No TJB, it will affect the whole brush.

But don't some people use bevel instead of null? Surely if you could go through the entire brush those maps would be unplayable.

EDIT: Let's face it, unless someone's going to go and test all of this stuff, none of us will ever know for sure.

Yes, or the world will end.

BEVEL isn't completely non-solid

So could you use bevel-textured brushes above models to create/accent shadows?

I never used bevel personally. at the end of my goldsource mapping i started using stokens' suggestion to use sky on unseen faces over nulling...

dude it's a decade since with zhlt u can make entities drop shadows, for ex illusionary or wall

today with vhlt u can make { texes drop projected shadows

if thats what u mean

yeah, even when i mapped goldsource i wasn't aware of half the things...

According to Zoner, the BEVEL texture is the same in almost every way to the NULL texture. However, if NULL starts providing a clipping error due to some circumstances that I'm not entirely aware of, BEVEL is used.

That said, shouldn't BEVEL be used all the time in place of NULL? I would say yes to higher, out-of-reach placed brushes. Then again no, because lower placed brushes would just appear illusionary and players would walk straight through.

It does make sense in a way, as a bevel is creating a new entire side of an object that is not perpendicular, so in Goldsrc clipping would be more complicated.

Source: http://zhlt.info/special-textures.html

@platoon, try this: http://filesmelt.com/dl/lessismore.jpg

Bevel creates bugs when angled. because of that the solid needs to be supported from opposing sides to stop angled beveled solids from being bugged up.

Example:The angled side of the triangle is textured, while the rest are Beveled. This crates a bug where the player can enter the solid to some point. By nulling the opposing sides you stop this bug from occurring.

SKY is also a great choice for solids ONLY. No clip nodes, no rendering. But it does drop light so you need to know where to use it.

A player can enter a solid? It's that what is happening when you can't walk properly on odd terrain?

Yes, thats whats happening. There exists moments where you can enter the solid on angled area and walk trough it and jump out from anywhere. Good example of this is Skalses Gold Source map with the helicopter, zm_frostbite.
You can duck and go below the ground at some areas, that is caused because bevel is used.

As far as i experimented, nulling certain sides of the solid stops this from occurring. You can probably use SKY as well.

Sky is better than null with angled because it works the same but doesn't create the bug. The only limit is that it emits light from certain angles (defined in light environment) and it can not be an entity.

I was under the impression that texturing a brush with both sky and normal textures caused errors. Is that just with older compile tools?

Nah, it even worked with older compile tools. You could texture everything with a texture (of one solid) and just sky where the light would emit or sky would show.

SKY is just like any of the special textures, except those who need to be 100% same on all sides of the solid (origin, clip).
This is not the case with sky. You can SKY any surface and leave it like that. It wont cause compile errors.

But as i said it will drop light and cause HOM. So use it on sides that wont be seen in normal conditions.
Experiment a bit. The only restriction is it MUST NOT be an entity.

Also check this thread, you might like it:

http://twhl.info/forums.php?thread=18292

I'll bear that in mind then when I'm mapping.
And I had run into the problem from the other thread before, I had been trying to make an artificial habitat with a holographic sky, as in itlooks like sky from below, but like some kind of transparent energy field from above. I kept running into the problem of the viewing platforms above being visible. If only that thread had been around then.

Yeah same here, but it seems valve has a trick for this, heh. I saw the same thing in Assault in CS GO. Exactly the same technique is used.