Why aren't my brushes making BSP splits!?

(PSIonic) #1

Hey everyone.

I’ve been working on a map the last couple of weeks and it’s beginning to look the way I want it. I’ve got one problem though. My walls aren’t causing BSP splits on touching brushes! This means that VIS isn’t going to be able to “hide” the inside of buildings from the exterior view of them… meaning bad FPS!!

Especially important are the double doors that lead into my main building. They are static doors that are half open so it is possible to move through them. I really need them to cause BSP splits or else they will not help VIS out!

Here is a screen of the double doors:


The doors span the entire height between the floor and ceiling so they are capable of blocking visibility from certain angles.

I have circled the edges of the doors where Q3MAP2 really should have started generating splits in the floor and ceiling.

I have tried selecting everything in my map (it’s not so big yet) and doing “Selection > Make Structural” but that didn’t make any difference.

Any help on this matter would be greatly appriciated!

(chavo_one) #2

I think you misunderstand what will and won’t be drawn by the engine when using the vis table. Just because you can’t visually see what’s behind the doors at certain angles does not mean that the engine won’t render it anyway.

If the portal you are standing in can see through the doors, then the engine has to render what’s there. So in other words, it’s not player point-of-view, rather portal point-of-view.

(PSIonic) #3

I know that. I only showed that angle because I wanted to show that Q3MAP2 isn’t splitting.

I’ve designed Quake 1 and Half-Life maps before and I’ve used Hint brushes to make doors such as these effectvely hide detail.

All I need to know for ET is how to make it treat brushes properly so vis can use them accordingly. It is as if my doors are being treated as func_walls for those of you familiar with Half-Life editing.

(chavo_one) #4

If those doors are not any kind of entity, and are structural and not detail, then they will cause a portal split.

Whether or not that portal split is enough to prevent certain portals from being drawn is another issue. You most likely will have to experiment with hinting.

Have you been using the portal viewer plugin in radiant to see the portals being created. I apologize if it appears I’m speaking down to you. It’s just that structural brushes will always cause a portal to be formed.

(SCDS_reyalP) #5

Is there a reason you are showing us r_showtris ? Just incase you don’t know, that tells you nothing about the bsp splits or portals. If you use r_showtris 2 it does show you what is being rendered, but that is all.

If you want to see where the portals are, us the portal viewer plugin.

q3map also has an order in which it does the bsp. It goes something like this: blocks, hints, normal brushes. It also prefers vertical and axial splits.

This http://www.planetquake.com/spog/stuff/technical.html might help

(PSIonic) #6

Thanks all for helping me out.

I thought the r_showtris triangle view would be the same as r_drawflat or gl_wireframe in Half-Life so it would show the edges of portals.

I didn’t know about the portal viewer plug-in, but now that I know I find it very useful! :drink:

One last finalising sub-question… is there a console command for reversing the drawing order or something similar in-game so that you can work out what the engine is actually rendering?

(chavo_one) #7

If you want to see every triangle being rendered by the game, type “r_showtris 2”.

(PSIonic) #8

Thanks chavo_one!

That seems to complete the picture for me. The double doors are hiding detail within the building very well now (and before I guess!). :smiley:

(ydnar) #9

The Quake 3 engine tools don’t split the world BSP the way that Q1/HL tools do. Since it was designed for hardware rendering only, it could get away with a looser, faster setup, the end goal being a clean set of triangles to toss at the hardware, as opposed to split polygons in a sorted BSP for software rendering.

Basically the BSP is still there like with Q1/HL, but it’s just a framework that the visible surfaces are hung on. It’s akin to an automobile’s body being bolted onto the chassis.

If a visible surface (wall, terrain chunk, tree, model, whatever) touches any BSP leaf in vis, then that surface will also be visible.

Mapping for ET is quite different than for Q1/Q2. There are some pretty broad changes with regards to optimizing the map, for visibility and triangle/vertex count. Bulding a map using the “caulk hull” method where nearly all the visible geometry is detail, and there’s only a simple caulk hull of axial brushes and hinting is one popular method.

y