#define MAX_MAP_LEAFFACES 65536

(dsargrad) #1

I’m eager to experiment with maps that have complexities/sizes that exceed the current limitations that seem to be hard-coded within the Q3 engine.

The specific limitation that I’ve run into recently is with the variable MAX_MAP_LEAFFACES.

The source code in the just released engine seems to indicate that this variable (and others) could be increased fairly straightforwardly.

What are peoples thoughts relative to the potential issues associated with this?

Is there a version of q3map2 that supports an increased hard-coded value, or better yet a command-line configurable set of values for parameters such as MAX_MAP_LEAFFACES.

All thoughts appreciated…
Thanks.

(carnage) #2

as far as i know, and that only a few steps

all compilers currenty run into their max limits before the engine does. look for socks talk about his work on the oasis map, he says that was constantly reaching compiler limits and doest apear to push the eninge very far so i would assume you will have to write your own compiler

maby u can get the q3map2 source?

(kamikazee) #3

But what I actually like to know: is it necessary to increase these things?

IMO I’d search for what the maximum is in map sizes and details using ‘clean mapping’ without hitting the compiler limits, but if you want to pursue in this research, carry on. I’m not holding you back.

(Detoeni) #4

MAX_MAP_LEAFFACES

If your getting that error then you might want to look into correct use of “detail” brushwork.

This error has nothing to do with size, only how the map has been (miss) made.

(dsargrad) #5

In terms of why I am driving this limit… it may have something to do with the fact that the map I am creating is extremely large. It may have something to do with the fact that I am using the wrong types of brushes.

Can someone point me to a good reference for detail brushwork?

If indeed the structure of the brushes is unnecessarily driving this limit then I will certainly change.

Which types of brushes impact the number of leaf faces and which will not drive this limit?

What is the downside (what do you lose in terms of the features of a brush) of using the kind of brush that does not drive the leaf faces limit?

Thanks for all comments.

(Twisted0n3) #6

Patches, entities (including mapmodels, func_statics, doors, and such), and brushes explicitly set to “detail” in Radiant (ctrl+M, or menu option). The latter have no particular limitations, other than that they will not cull pvs or block leaks. So if you made your map entirely with “detail”, you’d leak; if you threw a caulk box around it (not made detail!) it would quit leaking but the whole map would be drawn from every vantage. Normally, one puts non-detail (structural) caulk cores in the floors, walls, and ceilings and behind skies, etc. to keep visibility under control. The map then has this simple boxy layout of caulk, with a crusting of textured detail faces.

Overdraw prevention is the other major area that gets affected – bits of texture behind or on the back of detail brushes may still render, unlike on structural ones. It’s best to caulk every square centimeter of unseen geometry regardless.

There are minor problems that can happen as well: detail brushes can cause areaportals to leak (put structural caulk in all the walls, floors, and ceilings); detail brushes can cause light to leak (if you get light leaking under a stubby wall, for example, make it structural or put structural caulk inside it and look into hinting the areas on either side); and detail brushes may cause fog volumes to act up – to be safe, fog should be enclosed on five sides with structural brushwork.

This construction, done right, will speed up vis times drastically and avoid all the vis stage errors, notably MAX_MAP_VISIBILITY and the one you’ve hit, without significantly worsening framerates or polygon counts.

Note that brushes that use a shader with surfaceparm trans (notably, clips and such, and see-through grates, flames, and similar sfx) don’t block vis and may count as detail. (I’m unclear on whether surfaceparm trans suppresses the brush from producing bsp splits or portals, or just from being considered opaque by vis. They definitely can cause leaks, with the whole map or with areaportals.)

(SCDS_reyalP) #7

dsargrad:
You can get the source for q3map2 from http://zerowing.idsoftware.com/

It looks like ydnar already increased MAX_MAP_LEAFFACES once,
q3map2/q3map2.h


#define	MAX_MAP_LEAFFACES		0x100000	//%	0x20000	/* ydnar */

edit:
ooops, on reading the code more closely, my original comment was wrong. Revised below

edit #2:
See q3map2/writebsp.c:EmitLeaf

It looks like this error is related to the total number of drawsurfs in the map, so it isn’t really an vis issue. If I have understood correctly.

(Twisted0n3) #8

Looks like it was increased by a factor of eight.

If it’s not a vis problem but a “map is too darn big” problem, then it might well stand to be raised further. As beefier hardware becomes commonplace, bigger maps can run acceptably – if, that is, they compile at all. So why not let them? With the q3 source now out even an engine limit can be raised. Look how far the q1 engine’s been taken with darkplaces, tenebrae etc. – the q3 engine is going to produce offshoots equally impressive over the original given a few years.

(dsargrad) #9

Awesome feedback everyone. This is clearly an active and responsive forum… much appreciated. I’m actually hopeful now that I can fix my map in a fashion that will still allow me to grow much of the detail.

I’d appreciate clarification relative to two of the above statements:

First statement:

It’s best to caulk every square centimeter of unseen geometry regardless.

What is meant here? How do you caulk unseen geometry?

Second statement:

if you get light leaking under a stubby wall, for example, make it structural or put structural caulk inside it and look into hinting the areas on either side

How do you “hint” the areas on either side?

Thanks again. Nice to have some experts weigh in on a noobs struggles. :slight_smile:

(Twisted0n3) #10

Caulk – apply common/caulk (q3a) or equivalent (varies by q3 engine game) to surfaces not seen in the game. For example, at a corner, rather than two rectangles like this:

------||
------||
      ||
      ||

you build this:

-------/
------/|
      ||
      ||

and the diagonal faces get common/caulk. The horizontal and vertical faces that are actually visible are then wholly visible (no parts behind other brushes) and get textured. Back faces of, say, a protruding light are caulked too. So suppose you have a wall with a square light on it that sticks out. Simple construction is just a rectangular brush for the wall, with the visible side textured, and a small square brush for the light, with the light brush sitting right next to the wall brush and textured with some sort of light on the front and stuff on four sides.

Now you want the little light brush made detail, since it doesn’t block visibility of anything. You also want caulk on its backside and on the unseen sides of the wall brush. Moreover, you want to remove the overdraw from the wall texture continuing behind the light brush. This can be achieved by cutting the wall brush into five pieces: a square behind the light brush of structural caulk and four trapezoidal pieces, each of which has a short side that coincides with one side of the square, a parallel long side that is the top, bottom, or either edge of the wall, and a pair of diagonal sides running from two corners of the caulk brush to corresponding outer corners of the original wall brush. These four are structural and have texture on the visible faces, and caulk everywhere else. There’s a few more tris, but no overdraw. This is generally better: a handful of tris bothers modern video cards less than extra pixels to fill (which overdraw causes), and the older video cards where the tris might be problematical tend to display ugly z-fighting (striping that shifts) when there’s overdraw from two parallel and close together surfaces, like the wall and light in this case. (More modern cards seem to only show z-fighting when the surfaces are actually co-incident, or tangential, such as a texture continuing behind a curve that peels off, or a brush with duplicate planes, or two brushes in the same space.)

Hinting is a whole other topic. Basically it adds splits to the bsp and portals, but hints don’t block vis. Volumes inside hint brushes that cannot be connected by any straight line without it going through structural caulk or some other opaque structural brush will tend not to be considered able to see each other by the vis process. The classic use is a diagonal hint or two at a hallway bend or jog, so that outside a little triangular area at the bend or zigzag area at the jog, only one branch of the corridor gets drawn. This can be done vertically as well as horizontally, for instance if a corridor becomes a vertical jump shaft and then a horizontal corridor again. (So can the classic “doughnut” and other vis-controlling geometry.)

(obsidian) #11

A few of my all time favourite resources for map optimization:

Sample Map: An Explanation - By Q
http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20020703-6-020488.html?

My take on: caulk hull/overdraw/hinting - By Plan B
http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20020625-6-022411.html?

Advanced Portal and Hinting Optimization Tutorial - By Me :slight_smile:
http://www.quake3world.com/forum/viewtopic.php?t=3620

Hint Brushes: how and why to use them - By Spog
http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20010202-6-006065.html?

Hints - By Djbob
http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20020703-6-019324.html?