Going crazy with hint brushes Created 12 years ago2012-02-19 21:43:02 UTC by camplo

I've used hint brushes correctly in the past but tend to not like them because of how tedious it can be. I was wondering if you can get away with letting the hint brushes intersect with world brushes and other hint brushes.

.

It's 2012 man. Screw them

Not without protection, Bruce!

Bruce I am beginning to get that feeling. I can't imagine hint brushes will hurt anything if they intersect, let alone, compile times. So far my compile time is like 1 minute 45. Big whoop right...

I'm pretty sure hint brushes cut up geometry but i cant be certain. Its best to experiment methinks. turn on wireframe and see if you can tell the difference between having them or not.

And i do agree that the engine is coming up on 15 years old so our computers really shouldnt have any problems with the map either way.

How about making my clip brushes func_detail?

Func_detail doesn't exist in Goldsrc.

Does too

better act like you know.

Hint brushes do cut world. Learn to use pyramid technique if you really need to use hint. It makes a lot less cuts and is easier to join together. There is a tut somewhere on the net.

Soup: IIRC, the new VHLT includes func_detail. Though I'm not 100% sure on that, as I'm waiting for the new Compilator before I get them. (I'm sure it'll be out before I'm ready to make any final releases for GS.)

So I cant use hint/skip on func_detail or yes?

Hint brushes cut the geometry in the area where it is placed, that is all. You need not use them any more, because in most cases they will only result in increased w_polys.

hint and all that jazz has to be used on a world brush, you wouldn't tie clip or sky to entity, and for the same reason you wouldn't make hint func_detailed.

I doubt you understand what func_detail is, it's an entity very similar to func_wall, except it does not cut brush based entities, or world brushes. It only cuts other func_details. It's the same thing as func_wall but cuts only itself; It's only used to optimize your map in areas where you need func_walls but don't want them to be touching each other, if that makes sense.

Func_detail is what you do to stop small objects cutting large faces and increasing poly size in your map. That is all.

Clip has nothing to do with polygons.

HINT and SKIP are used to cut VIS-leaves. Cutting planes is a side-effect which is necessary to create valid VIS-leaves. Sometimes HINT creates new leaves without cutting planes.
So the main purpose is not optimizing poly-count. It only reduces the poly-count because:
(a) there are sometimes better solutions to cut planes than CSG and BSP calculate (there is no need to use HINT/SKIP in this case, because you will reduce the poly-count only by 1 or 2)
(b) due to the fact, that HINT/SKIP cuts VIS-leaves, it's possible to hide surfaces from being calculated by the engine. Normally the engine calculates all the polys which are in the VIS-leaves you see (also the polys you do not see as long as they are in the VIS-leaf!). With HINT/SKIP you make the amount of polys in visible VIS-leaves smaller, so less polies are calculated. (In opposite to this there may be more polys generated by the compilers, but less polys are calculated at every position you can stand at)

Of course this only works if you use HINT/SKIP correctly.
If you use lots of point entities (like cycler_sprite to display models) it is is necessary to use HINT/SKIP, because it's possible that the model's center is not in a visible VIS-leaf and this would make the model invisible (the VIS-leaf containing the model is not rendered).

Info: Maybe you should do some research about "potentially visible set" (PVS). HINT/SKIP influences the compile process, when VIS calculates the Matrix of the PVS.

func_detail is a mix between world_brush and func_wall. Like func_wall it does not cut other world geometry. Only other func_details, whose detail_level is the same or lower, get cut.
A Func_detail's clipping hull can be removed (make it similar to func_illusionary).
In all other points it is equivalent to world geometry. It casts shadows, it blocks VIS, and so on.

use any batch compiler, either Nem's or the Compilator, and change the VIS nodesize to 256 or 128. This will result in more frequent checks for opimizing than the default 1024 setting and will result in lower poly counts. The price is obviously a longer compile time. This works better than any hint or skip brush set up.

A Vis Node is an area that when the player enters it, it quickly loads and unloads what is visible from that area. A large area means that everything visible from that area must be loaded even if it isn't exactly visible by the player. A smaller area is more precise in this. Any loading/unloading performance issues is a non-existant problem on modern computers.

You will still have to null or bevel unseen edges, and make all of the expected optimizations yourself, but you won't have to worry about hand-placing hint brushes.

"func_detail is a mix between world_brush and func_wall. Like func_wall it does not cut other world geometry. Only other func_details, whose detail_level is the same or lower, get cut.
A Func_detail's clipping hull can be removed (make it similar to func_illusionary).
In all other points it is equivalent to world geometry. It casts shadows, it blocks VIS, and so on."

Now thats good to know. So if I make every other brush a func_detail I'll have my shadows and lower my w_poly theoretically. When I was under the impression that func_detail didn't block vis I turned choice brushes into func_detail only to have a small increase in w_poly but very small. Since it blocks vis and it would make sense to, for example, make the walls of a building func_detail while the ground is a world brush thus eliminating cutting there. My node size is already 64 and if I could make it smaller I would...but cannot. I still see room for improvement....Its not like I enjoy using hint brushes but lag is an issue when mapping for a online server. I did some more studying today and came up with this. At 800 w_poly and 38800 e_poly my machine lags about 2-3fps. What I could not conclude to is how many players were being drawn to create 38800 e_polys but I think I know how to figure it out. So in a nut shell the less players being drawn the less e_poly will be the less frame lag there will be. The e_poly from my experience has always been the main influence on lag online. It is still evident that w_poly plays a small role allowing for maybe 4000 more e_poly before lagging if the w_poly is something low like say under 400 w_poly. Long story short simple use of hint brushes always beats vis even at a node of 64(subdivide is 256).

what really is unclear is the detail 1,2 and 3. I just set them to 2 because according the post of the new vhlt tools, 2 doesn't cut anything.

" A large area means that everything visible from that area must be loaded even if it isn't exactly visible by the player."

That is untrue with hint brushes.

"So if I make every other brush a func_detail I'll have my shadows and lower my w_poly theoretically."

That's not right. func_detail still cuts other func_details. It does not make sense to make everything func_detail. Sometimes it makes more sense to not use func_detail because the cutting of a world brush creates a leaf portal. Excessive use of func_detail will increase w_poly count.
If you make ALL the world brushes in your map to func_details of the same detail level you won't notice any difference to world geometry. So only turn brushes to func_detail if it really is detail.

"Since it blocks vis and it would make sense to, for example, make the walls of a building func_detail while the ground is a world brush thus eliminating cutting there."

Bad idea. The func_detail blocks vis, but the floor has to be in one VIS-leaf. So for the engine the objects on the floor are in the same VIS-leaf as you and renders them though you can not see them.

"The e_poly from my experience has always been the main influence on lag online."

w_poly is world geometry and e_poly is model geometry.
w_poly is slow and e_poly is fast. This makes w_poly cause more lag. The difference is, every w_poly could be rendered alone while e_polys are always displayed as a group.
I.e. you have a 6-sided cube (world geometry) but only see 3 sides. Then you have 3 w_poly.
If you see the same cube as a model all 6 sides are calculated because you can see some part of it.
So if a high-poly model or player is in your field of view, then the e_polys increase by 3000 or so, and if there are lots of players there are more e_polys that the engine renders. So e_poly cause lag, only when there are many of them.
gimli posted a wpoly-epoly-ratio some years ago which can be used as reference:

100 wpoly + [x100] 10,000 epolys
200 wpoly + [ x45 ] 9000 epolys
300 wpolys + [ x25 ] 7500 epolys
400 wpolys + [ x15 ] 6000 epolys
500 wpolys + [ x10 ] 5000 epolys
600 wpolys + [ x8 ] 4800 epolys
700 wpolys + [ x6 ] 4200 epolys
800 wpolys + [ x4 ] 3200 epolys
900 wpolys + [ x2 ] 1800 epolys

These values should work fine on every machine. There should not be more than 1000 wpolys + 5000 epolys in a place. More than this will cause lag on nearly every machine when playing in multiplayer.

what really is unclear is the detail 1,2 and 3. I just set them to 2 because according the post of the new vhlt tools, 2 doesn't cut anything.

world cuts world and all detail levels.
detail level 1 cuts detail level 1,2,3,4,... but no world
detail level 2 cuts 2,3,4,... but no world or level 1
detail level 3 cuts 3,4,... but no world or level 1 and 2
and so on

" A large area means that everything visible from that area must be loaded even if it isn't exactly visible by the player."

That is untrue with hint brushes.

I think Rimrook is right. Large areas are "open" areas. In open areas you can see all VIS-leaves. Cutting it into more leaves with HINT makes no difference. You can still see all VIS-leaves.

One more question: How did you get subdivide 256 working? When I try to set it to another value higher than the default 240 there are tons of errors :/

I'm too noob to know why actually. Maybe your map contains less complex shapes than mine? Did you install that thing that makes hammer export maps more accurately?

To your other statements in no particular order. Large areas and large open areas are not the same thing at all. A large area could have a huge building in the middle thus blocking vis until you climb to a height that is impossible to not see all other vis leaves.

About the e_poly vs w_poly. Most of the maps on the server have w_poly under 1000 and a lot of the times are almost always lower than or in the range of 500 w_poly. We have maps where the w_poly hits 1200, maybe a lil more in others. We have maps where w_poly never breaks higher than 350. Still the lag is directly tied to the e_poly from my experience. The lower the w_poly the more e_poly you can handle but pretty much NO MATTER WHAT when the e_poly hits 30-40 thousand and beyond, fps drop linearly as e_poly rises further. Don;t matter if the w_poly is 1000 or 100. The difference I think is something like 10 thousand e_poly's more the engine can handle before lagging when you have really low w_poly

"That's not right. func_detail still cuts other func_details. It does not make sense to make everything func_detail."

Well I thought if a brush isnt touching another, it wont cause it to cut. So I figure if a had 4 touching brush lined up and made, key word here, every other brush a func_detail, then no brush would be touching another brush inside its group, in other words. WorldBrush||Func_Detail||WorldBrush||Func_detail
Now no brush is touching another brush that would cause cutting. Does it not work that way?

"Bad idea. The func_detail blocks vis, but the floor has to be in one VIS-leaf. So for the engine the objects on the floor are in the same VIS-leaf as you and renders them though you can not see them."

I dont understand...The floor has to be in one vis leaf? you lost me. If I have a room sealed into two separate compartments by a wall that is func_detail....I still see whats on the there side?

Forgive me for being a noob, and thank you for responding!

I've seen in both de_train and de_nuke, that they lift a brush 1 unit away from the other brush, and on the bottom of the elevated brush, they change the face to "{invisible".
You can see this in the the box right beside the container at T spawn in de_train, the box right beside the bigger box at ramp in de_nuke; there's a few other maps aswell, though I can't remember them all at the top off my head.

The separation of brushes to stop cutting is old news. I just started mapping this year and tutorials I have read that included such things are pretty old. But making your touching brushes alternate between world brushes and func_details is another beast. Sounds like it would work to me though. I bet someone knows for sure.

No wonders, that solution has been used since the game was released; I just added a small little detail I didn't see anyone else mentioning.

I made a map once where way too much was separated for the sake of optimization....cause thats the kinda person I am.

That's not right. func_detail still cuts other func_details. It does not make sense to make everything func_detail.

Wrong, func_detail can be set to not cut anything, even other func_details.

yeah according the post of vhlt, detail level 2 cuts nothing...