VIS Optimization Query

[PaN61]

Is VIS Optimization still being used by mappers to this day? Given the technological advancements from the early 2000's to now, should you even worry about VIS optimization at all?

Regardless if it's being used or not, I vaguely recall there being multiple methods of optimizing the VIS component of maps. I know for a fact that HINT brushes are used to do this and was it AREA PORTAL brushes too? I was just wondering if anyone could explain (hopefully in-depth) how to use these brushes and what they exactly do in regards to map optimization, as in, what objective do they accomplish?

I'm not exactly sure if these are the only optimization techniques so if there are (by chance) any others that I'm not aware of, it would be good to gain a bit of knowledge about them for future reference.

[CZghost]

The much I know about BSP tree space splitting by hint and area portal brushes is not so heavy knownledge, so only in quick:

Hint brushes may be used in a large area with a lots of VIS details and where the VIS could not be so easily blocked by default (take a look in example map q3dm7 in the RL chamber). Hint brush splits a face to multiple tris count along by brush edges, which then helps to reduce rendering contents that are not seen - are hidden behind a solid wall.

Area portal brushes are for blocking VIS through closed doors. Extra-slim brush should be tall and wide at least at the whole size of the door hole. Do not use this at doors that are explicitly opened, the game has a bug that prevents viewing the contents behind door when opened, not when closed, which results in HOM effect. No example map given with Radiant have this shader used, though...

Similar are Cluster portal brushes, which are used by BSPC to compile AAS file. It is simply Area portal for bots and should be used anywhere in a gateway where door is not used. However it works like a waypoint for bots, which attracs them to go in that gateway. Used again and viewable in q3dm7 example map. It has no effect on BSP VIS, though...

I think ydnar would tell you more, if he would. Then there is obsidian who took Q3map2 under his wings, he should know much more than me...

[dONKEY]

A little searching, perhaps....
http://www.quake3world.com/forum/viewtopic.php?t=3620

[Hipshot]

I care, but for me it's more about keeping the triangle count at a max ~50k in places where I just can HINTaway the problem.

[AEon]

Had totally forgotten about obsidians nifty, pictured take on hint brushes and vis.

Alas the problem is and always will be... as soon as you use more open (and often that makes more interesting maps, away from strictly corridor/room/corridor) layouts there simply is nothing to block the visibility view, so it's almost impossible to block vis...

Relevance in modern games... well in Reflex they use a completely different system, they do not use vis calculations like Q3A does. It seems to be based on some form or real-time sampling to find out what can be seen and needs to be drawn and what not... I forgot the new term though. So for Reflex we pretty much ignore the whole, build a solid wall here to block all the stuff behind it. Trouble is, so far Reflex has no wireframe view, that would let you check what is actually drawn behind walls.

[CZghost]

To be honest, if you use large and open map, and you wish to use map-scale fog, you can set up fog hull shader and far-plane distance, which will block rendering planes further than the maximum distance to draw. It also helps a lot to render, but you also need to use the hint brushes, which will split that large area to multiple small sections.

[PaN61]

I tried doing a search with Google prior to asking but unfortunately didn't get explicit answers to what I was looking for.
Thanks for the link, Donkey, really helpful and on-point article.

I understand mostly all of the article, however, the problem I'm finding most difficult to understand is seen in the 4th last picture.
As seen in that 4th last picture, the hint brush is placed in between the 1st and 2nd floor through the hole in the 2nd floor. I understand that this creates one portal instead of multiple portals for that area which theoretically reduces the power needed for VIS calculations, however, wouldn't that area still be rendered by the engine due to the fact that you can still 'see' that area from almost all positions on the 2nd floor resulting in counter-productivity?


I also have a few questions regarding this paragraph:

Keep in mind that the blocksize also generates portals every 1024 game units along every axis. You can increase/decrease the size of this by adding the _blocksize worldspawn entity key/value pair. You can also set it to 0 to disable if you're comfortable to generate your own portals - though you should avoid this unless you really know what you're doing. When building your layout, you may want to build your floorplan keeping the blocks in mind.

Does this literally mean at every 1024 unit increments from the origin the compiler will automatically set up the VIS portals so that there has to be at least one at either side of the 1024 unit plane and thus this plane being an intersection of VIS portals? Does increasing this value help in reducing these non-useful portals? Also, in having this block size parameter disabled, would you theoretically have to create your own portals using HINT brushes throughout your entire map?

[obsidian]

id Tech 3 is an old engine. Which is why even though graphic cards can now pump out billions (trillions?) of polys, Q3 can only work reliably in the under 1 million range. Q3 can't take advantage of the new architectures so it's bottlenecked. That's why optimizing your maps is still very important.

Vis does more than just limit visibility. While it is primarily used for visual optimizations and eliminating parts of the map that you can't see, the data generated is also shared by other parts of the engine, like bot optimization.

I understand that this creates one portal instead of multiple portals for that area which theoretically reduces the power needed for VIS calculations, however, wouldn't that area still be rendered by the engine due to the fact that you can still 'see' that area from almost all positions on the 2nd floor resulting in counter-productivity?

Precisely. The goal of that hint brush was to remove the weird vertical slivers which are completely useless anyway. It doesn't do anything by way of directly blocking visibility to the floor below, but may help in reducing the overall number of portals, and may help with hiding other parts of the map further down the PVS-table not visible in this part of the map.

Blocksize: Yes, by default, every 1024 units a solid cut is made straight down across the map. I don't believe this was created so much as a visual optimization, so much as it is for bots and limiting cluster sizes. I'm no expert on bot code, but I believe bots are very limited on memory and can't function very well with larger complex clusters. So the thought is that at worst, you have a cluster size of 1024 units.

I suppose if you were absolutely keen on it, you can disable blocksize and optimize everything manually and everything would be fine. On the other hand, leaving it on and even though it may not be super clean and optimal, it probably wouldn't be terrible either. I mean, the goal here is to help the compiler along and make some manual choices here and there, but you probably don't need to be an absolute hint-nazi about it in practice. I am but only because I'm being academic about the subject.

There was someone's map on this forum (forgot who) whom I was helping optimize and I showed what happened when I selected his entire map and moved it a few units around. Even without hints, by moving things to line up a little better with the blocksize made a pretty big impact already. Just doing something like that might be all that you need to do.



Further reading... This is a work in progress so it's very incomplete and has missing pages, but seems like something that you might enjoy. Let me know your thoughts. Also has links to other articles by myself and others:

idTech3 Optimization - article by Obsidian

Hint brush splits a face to multiple tris count along by brush edges, which then helps to reduce rendering contents that are not seen - are hidden behind a solid wall.

CZghost, you don't seem to know how things work, so please stop inventing things since it results in misinformation, and your mixed bag of terminology is indecipherable at best. Hint brushes have zero effect on surface geometry.

[dONKEY]

I suppose if you were absolutely keen on it, you can disable blocksize and optimize everything manually and everything would be fine.

IIRC Sock did exactly that for POM. In a thread here somewhere he posted an illustrated explanation of the process.
Without being mean, that would probably be a little beyond most mere mortal mappers

[PaN61]

Thanks for the explanation.

I've noticed that you use the 'Skip' common texture for all sides of the brush besides the side that has the 'Hint' texture on it. But, when I read the GTK Radiant manual (Essentially the same as the original ID Software manual for Q3 Radiant) it says this:

Skip
Location: (textures/common/skip)
Color: Transparent yellow
Game Function: Do not use in Q3A. This texture was used in Quake 2 maps to discard sides of hint brushes. It is nonfunctional in Q3A.

So if this entity texture is not functional in Q3A, why are they used on 'Hint' brushes then?

[obsidian]

The manual is really really old. Skip was reintroduced with Q3map2. It is your awesome friend.