Visdata size is dictated by the number of leaves in the bsp, or rather the structural complexity. Vis time is determined solely by compound portal complexity. lights, entities, and surfaces do not affect it at all. What I mean by “compound portal complexity” is:

portal count (p) compounded by its “real” visible set of portals (s)

Take a large, open terrain map for instance. By default, Q3Map splits the bsp every 1024 units in the x and y dimensions. The large open space of the map is getting subdivided into (1024 x 1024 x height) sized volumes, each with 4 portals leading to its neighbors. Say this map was 32768(x) x 32768(y) units in size. 32768 / 1024 = 32, so it’d be chopped up into 32 x 32 blocks, totaling 1024 leaves. That’s 3968 inter-leaf portals (4096 - 4 * 32). While the visdata size would be approximately 128kb, there are still nearly 4000 portals that can all see each other. So while p is relatively low, s is very high.

I can’t claim to know Q3Map’s vis code very well, it’s a hairy mess that I’d just as soon leave alone. But, as I understand it, it works essentially like this:

For every pair of portals a and b, create a passage between them. (a tunnel, if you wish, terminating at each end with a portal). Clip this passage to all the portals between the pair. If the passage hasn’t been clipped out of existence, a can “see” b. Since leaves are convex hulls, bound by portals and faces, you can then assume that the bsp leaves that portal a and b are connected to can also “see” each other. “Aha!” you might say now, “That’s why vis takes so long on large open maps. There are so many portals to consider between any given pair.”

No programming tricks in the world can make a computer run faster. the only thing you can do is make a computer do less. The “caulk hull” method of map construction aims to minimize vis data, and vis computation time, by simplifying the structural complexity of a map, and therefore its p and s.

ok, enough bs, gonna get some food

y