P.S.A.: Rant about using brushes where patches should be used.

[Neon_Knight]

If you, as a mapper, insist on using brushes instead of bezier patches/curves where you should be using the latter, then you shouldn't have the right to complain about OpenArena's performance. IT'S THE QUAKE 3 ENGINE, FFS! Bezier curves and patches are there for a reason!

[Neon_Knight]

Here's the explanation for my rant.

I have created many rooms in a test map in order to see what happened in different situations. The test map is attached in this file.

First I wanted to see what happened if a brush (or bunch of them) was left as structural in the middle of a map. Here's the starting situation. Three structural triangles left in the middle of a room. The map was compiled using -saveprt in the VIS stage. VIS portals are portals which the engine uses to calculate how many things a player can see in a determinate place. See how many VIS portals were created, some of them truly unnecessary.



Here's one of the situations I've been seen suggested a lot. In order to draw less VIS portals, use brushes with common/nodraw on the non-visible faces and common/caulk on the visible ones. This, unfortunately, has the risk of creating the dreaded "Hall of Mirrors" effect in the game, so, in spite of actually reducing the tris count (and working in many situations, it isn't as good as it should be.



Image 3 has the same bunch of triangles, but this time brushes completely draw with common/hint were used. The situation... improved a bit, however, more unnecessary portals were drawn.



Image 4 has the closest thing to an optimal situation. It's a mix of 2 and 3. Visible faces have common/hint, while non-visible ones have the nodraw equivalent to hints, common/skip. Notice how the amount of portals was (almost) the same as with #2, however there were some extra portals drawn, but none too incisequential. As an exchange for this, though, there are no Hall of Mirrors effect in the game.



Now onto the corners. This is where my point starts. The next 4 tests were done without hint brushes.

The first set of tests was done with an L-shaped corner. In image #5, the "rounded" corner was done with a structural brush. Behind the walls, also, there was an empty room. This is usually a situation where the brushes are used for more than one room. Notice how it creates many unnecessary tiny portals.



Next test is the same rounded corner, but with no room behind those walls. The situation hasn't improved much.



Now to the patches. In image #7 a patch was used instead of a rounded corner. See how the situation improved a lot. Though it isn't optimal still, as the example features an empty room behind the wall.



Image #8 is a lot better. With that extra room gone, now two perpendicular portals were generated, which are closer to what we need to optimize our map.



For reference, also attached are the 8 room examples.

[Neon_Knight]

Now onto the second part of my argument. We're taking the last 4 rooms and applying hint brushes (as done in image #4) to them, to see what happens.

Here's the brushed corner with the empty room behind. Turns out we made the situation worse.



Here's the brushed corner with no empty room behind. The situation, again, was worse.



And with the patched corner with empty room behind? The situation improved a lot. Now VIS only draws two portals blocking the parts the players aren't supposed to see.



And the same happened with the "non-empty room behind" example:



Now onto the U-shaped corners.

Here's an unoptimized U-corner made with a structural brush. Tons of unnecessary VIS portals which don't do much.



With a patched corner? The situation improved a lot, but it isn't still optimal. But it's a big step forward.



Now let's apply hint brushes to these corners. Two hint brushes (with skipped faces, as done in image #4 of previous post) were used, and they start at the end of the room and pass through the point where the straight wall end. Here's the unfortunate result with the brushed structural corner:



And here it is with the patched corner. Four portals were created, though the engine won't render what the players cannot see.



The point of these examples are to call attention to a performance issue, because one of the many complaints about OpenArena is about how slow it runs in many maps. Ignorance of the common/caulk texture alongside unoptimizations like these and the denial/bad usage of hint brushes (I shall create a thread later for that) make the maps run slower despite how they look. Not to mention that brushed corners cannot be LODed (this is why this year I've dropped -patchmeta from my compilation scripts, at least the Windows one, I need to update the Linux one as well, fromhell was right, and I shall have done that before).

So, the bottom line is: don't use structural brushes for corners, gentlemen! Use patches instead!

[Gig]

For the round corners things, I think I got the essence, although I got lost in some details.

But a thing which makes me scratch my head when using curves (patches)... I do have problems with aligning their textures with surrounding brushes and it looks like trying to scale their textures does not work. Do you have some good hint about such problems?

[Neon_Knight]

Using a different texture is my first choice, considering small rounded corners are supposed to be trims of sorts in order to break texture repetition. And in case of large rounded corners, using trims at both sides of the corner and any texture in the middle.