q3map2 custom compile settings

(ACROBAT) #1

When I go to edit project settings and I pick the “final compile” (the one without without bounce 8) because I want to customize it I see the following:

MenuTest: bsp_Q3MAP2/Q3MAP2: (final) BSP -meta, -vis, -light -fast -filter -super 2

Command: ! “C:/Program Files/GtkRadiant-1.4/Q3MAP2/Q3MAP2” -v # -game jk2 -fs_basepath “C:/Program Files/LucasArts/Star Wars JK II Jedi Outcast/GameData/” -meta $ && ! “C:/Program Files/GtkRadiant-1.4/Q3MAP2/Q3MAP2” # -game jk2 -fs_basepath “C:/Program Files/LucasArts/Star Wars JK II Jedi Outcast/GameData/” -vis -saveprt $ && ! “C:/Program Files/GtkRadiant-1.4/Q3MAP2/Q3MAP2” -v # -game jk2 -fs_basepath “C:/Program Files/LucasArts/Star Wars JK II Jedi Outcast/GameData/” -light -fast -filter -super 2 $

Ok so wikipedia recommends the following for final compiles, and I’ve heard other say that similiar recommendations so I want to implement the following (except patchshadows because I have those in my sky portal and I think it will mess it up.)

“C:\path o\q3map2.exe” -skyfix -meta -v “C:\path o\mapname.map”
“C:\path o\q3map2.exe” -vis -v “C:\path o\mapname.map”
“C:\path o\q3map2.exe” -light -shade -patchshadows -samples 3 -samplesize 1 -thresh 0.1 -v “C:\path o\mapname.map”

Anyways when I look the command line there are two places I wonder where I should add -skyfix to? Right after “Q3MAP2/Q3MAP2” like wikiepedia says or should I put it right before the -meta like wikipedia also seems to hint at?

I mean modifying the “-light” phase is pretty simple, but modifying the -bsp and -vis stage confuse me. I plan on deleting -super and -filter and probably -fast also and putting in the changes wiki recommends, but where woud I put -skyfix and -v in the bsp and\or -light phase

(obsidian) #2

That wiki suggestion sounds outdated/wrong as a generic compile. (Upon reviewing the Wiki history, seems as if people have been mucking around with it without really knowing what they are doing). You wouldn’t usually use -shade, -thresh, or even -samplesize unless you had reason to.

A generally good final compile will contain the following switches:

BSP: -meta (-skyfix if you want to use the skybox seams hack on normal skyboxes, or use a portal sky instead)
VIS: -vis
LIGHT: -light -fast -patchshadows -samples 3 -bounce 8 -gamma 2 -compensate 4 -dirty

You may need to tweak it as necessary. There are a lot of features with Q3Map2 so don’t randomly add switches without knowing what they actually do. If you don’t know any better, just use the above and you can expect fairly decent quality compiles.

-super is an older switch, you should use -samples instead.

-fast is usually a good idea, since the loss of quality is not noticeable, but it is a LOT faster.

-v means verbose, and can be applied to any stage that you may find it necessary.

(ACROBAT) #3

obsidian,

I map for jko and jka, and I use fake normal mapping and phong shaders sometimes as background information.

When would I want to use “samplesize 1” in my compile? I used it in my last compile and I thought it looked good , but I don’r really know what it did?

I was told samples and filter did more or less the same thing, but that super was similiar but slightly different. Some mappers like Immenor like to use samples and filter together because they say it looks better. I asked Szico and Norman and both of them use samples but leave filter and super out entirely. Am I correct in thinking all three of these do vitrually the same thing or is super something that is different?

Szico told me he likes to use -patchmeta and subdivisions to make his cylanders look better also, but I’ve never used that.

Gamma 2 I have never used, but my impression was that it just makes thing brighter? Why not just make each individual enity or light emitting shader brighter? Since I’m ampping for jk2 I should probably not use this or compensate?

Thresh-Szico said he tried using this, and he can never tell that it does anything whatsoever even when he is looking at normal mapping or a phong shader so he does not use that.

As for bounce 8, a lot of the jko and jka mappers do not like that command because it will make you map much brighter all of a sudden after your final cmpile. Then you have to go back and lower all your light entities to lower levels so that the map is not ultra bright, and you’re never sure it looks any better than before you used the bounce 8? I also read in the forum history of this forum that YDAR used to use a bounce 2?

Lasly- dirty. I’ve never used that one so I’m not sure what it would do.

(obsidian) #4

You might need -samplesize for lightmap normal maps… it increases the lightmap resolution. But keep in mind that you need to be very careful about how you apply this to your map, since it increases lightmap data significantly which will certainly affect performance. I don’t usually recommend using the global (read: affect the entire map) -samplesize switch, instead it’s better to use the shader q3map_lightmapSampleSize directive to scale resolution per shader material or the func_group entity key _lightmapscale for per brush control. These gives you much better control over lightmap scaling so you can use it only on normal mapped surfaces, leaving generic surfaces at the default luxel resolution.

Samples and filter are a little bit like opposites actually. Samples increases the number of samples that Q3Map2 uses to generate luxels, usually resulting in sharper shadows. Filter applies a gaussian blur effect to lightmaps to smooth out shadow edges. You can use them together to a limited extent. Super was the old code that is being replaced by samples, resulting in better quality and I think compile time too.

-patchmeta + subdivisions will prevent patches from using LoD (Level of Detail) optimization, it will look “better” in that patches won’t be down-sampled to their low resolution counterparts when the player is far away and will always have a high tessellation. LoD is a performance optimization, so disabling it will affect performance, so use with caution.

-bounce enables lightmap raytracing. For accurate lighting, it improves quality by quite a lot since it actually raytraces your lightsources with accurate colour sampling with each bounce (see ydnar’s Cornell Box tests). Bounce does take a long time to compile, so sometimes for a good lighting test, bounce 2 will do an okay job though not best quality. Bounce 8 is a little overkill, but Q3Map2 will automatically cull unnecessary bounces, so setting bounce 8, it may in fact only do 5 bounces before halting. Maps may appear brighter, since it is calculating radiosity, but if need be, you can adjust it back down with -gamma (more on that later). See the Wikipedia entry for radiosity, the screenshots should give you a good idea of why -bounce will increase quality significantly.

-dirty enables ambient occlusion (sometimes referred to as dirt mapping), which is an algorithm that simulates light attenuation due to occlusion. In a nutshell, better radiosity quality.

-gamma allows you to control the lightmap gamma settings. So if you find that bounce scales the lighting up a bit, you can scale it back down using -gamma. The value “2” is more or less a fudged number that looks approximately right, you can use 1.8 or whatever if you want it to be darker.

-compensate err… compensates for r_overbrightbits 1 used for some Q3e games (Quake III Arena, for example) and is used with -gamma to control lighting back down to an acceptable range should colours get clipped. You may or may not find use with this with JK2, I’m not sure.

BTW, these are ydnar’s recommended base compile settings, not mine though I do use them.

Hope you found this helpful.

(ACROBAT) #5

Ok since I map for jko and jka, I will assume that I should not use gamma since there is no compensate in jk games. jk games do not use r_overbright bits.

My last question is will -fast affect fps? Once the lightmap is generated, it has no affect on fps correct?

(obsidian) #6

No, -fast doesn’t affect in-game performance, it only affects compile time.

(ACROBAT) #7

thanks Obsidian,
I keep coming up with more Q’s though. Is there a way to localize the -thresh 0.1 command? And if there is, would it have any real impact on bump mapping or would it be useful for anything specific hat you know of?

Also I’ve asked other people this. I’ve always wondered what a leaf node is supposed to look like. A convex triangle? During the bsp stage your map devides everything into them. Any square I can see is devided into these triangles here so I know they are some sort of triangle.

(kamikazee) #8

The “shape” of a leaf node can be thought of as a brush: a convex volume defined by four or more planes. It’s a volume with no vis-blocking geometry left in it.
So if everything is detail except for a caulk hull, the leafs will be large volumes. If you have mostly structural brushes, the leafs will be small and many. Because each leaf needs to know which other leafs are visible from

Play around with the Portal plugin for GTKRadiant if you like, it shows how the level was split into leaf nodes and shows all the portals. (Portals are the planes used to bound the leaf node.)

(ACROBAT) #9

Ya I’ve used show blocks option under view, and I’ve also imported the PRT files before so I know what the lines look likes. You can also turn them on in game, r_showportals I think? anyway

Rich Diesel says in his jk mapping tutorial that so many people use

“Compiling a map occurs in up to three stages. The first stage is the BSP process, or Binary Space Partitioning. This process takes your MAP file and first creates a BSP file. All the space inside the walls of your map are divided into convex shapes that are called Leaf Nodes. All the major sections of the Leaf Nodes (that aren’t separated by solid brushes) are turned into Portals. The portal information is recorded into a PRT file. A portal is basically each and every largest possible completely open area existing in your map with a convex shape (a small empty box of a room only has 1 portal - the entire room. Two empty square rooms connected by a straight hallway will have three portals - each room and the hallway.)”

I would think any square room would have at least 2 leaf nodes and maybe two portals? Look at the picture i posted above. When I look at the tris lines in a map I always see squared divided into traingles. When you say leaf nodes have four sides, to me that means they must be triangles. As for the convex part that never made much sense to me. Seeing portal lines in gtkradiant doesn’t really let me understand what a leaf node is shaped like.

(kamikazee) #10

The thing you are quoting is another issue. The Q3 engine works only with triangles to display surfaces. This is because the points used to define the triangle always lay in one plane so they are drawable. Quads on the other hand can be broken if one corner-vertex gets lowered and thus would introduce new problems for the renderer. So that’s why quads are always split into triangles when dealing with games.

Back to leaf nodes: those things are completely defined with planes. You are right that a leaf node with 4 planes bounding it will only have triangles as it’s bounds.
However, I said “4 or more planes” defining the volume. This means that cubes are represented by 6 planes. When they intersect, they form 6 squares and no triangles are involved.

As for the Portal plugin: move into the first cube you see with the portal viewer. Now you are in a leaf node and all planes around you bound the leaf node. The lines you see are the lines formed by two planes intersecting each other. And the surface these lines bound on one plane is called a portal.

I’d really need some screens to explain it. Maybe there are some to be found on a tutorial about the portal viewer.

(obsidian) #11

I wrote such a tutorial at Quake3World. You guys might find it an interesting read along with the long list of other resources that I’ve linked to on that page…

http://www.quake3world.com/forum/viewtopic.php?t=3620

(ACROBAT) #12

I looked through all those tutorials on hint brushes, and I was pretty familiar with all of the content.

I was wondering about using hint brushes for a different purpose though- reducing the total number of leaf nodes generated during the -vis compile.

Say I have a gigantic room. Why not cover the entire room with a square hint brush so as to combine all of the leaf nodes into a gigantic leaf node. That way there is only one zone in the big room. People who get max_visibility erros during compiles- wouldn’t this solve the problem? If I were going to start disabling blocksize altogether, this is essentially what I would need to start doing no?

(obsidian) #13

If you have a single square room (regardless of size) and blocksize disabled, you will only have one leaf node anyway, with or without hints.

(ACROBAT) #14

Well I mean in most ffa maps I have a series of square rooms connected by L or Z shaped hallways. I still will have only one leaf node per big room?

Would doing the giant hint brush thing speed up compiles or accomplish anything at all?

(obsidian) #15

Maybe I’m not understanding your question completely… if it’s just a big square room with no other structural brushes inside it and blocksize disabled, why would it generate more than one leaf node?

If you want to test this, build a simple room, compile and load up the .prt viewer.

(obsidian) #16

…Unless you mean if you have a big room full of other structural brushes and if you can simplify it by merging them into a single node by placing a single hint brush across the entire room…

In which case, no, hint does not work like that. It can’t merge portals, it only can create them.

(ACROBAT) #17

This box is 2024X2024X2024 with default blocksize. I realize I could just change _blocksize from the default 1024 to 2024 and I would reduce the four portals shown on the X-Y to just one, but I need to understand hint brushes for larger areas.

I read an online tutorial for hints that claimed hint brushes could overide the portal lines and even structural brushes. So in that picture, I hid the roof and put a hint brush over the entire thing just now. Wouldn’t that merge all four leaf nodes (or 8 if you count the Z axis too) into one giant leaf node? I makes sense to me that you want as few leaf nodes as possible so any square room should always have one leaf node, yet the default portal lines devide things much more finely so that large rooms may have many leaf nodes (basically one leaf node every 1024 units.) Or if the portal lines are overiding my hint brushes, then the alternative would be to shut of the portal lines so they aren’t messin things up and use all hint brushes for portals in the map?

(obsidian) #18

As I mentioned above, hints can’t merge nodes. That’s not how they work.

I think you are putting to much effort into this and not looking at the bigger picture. On an unoptimized map, you may have some thousands of nodes. Using the caulk-hull method and converting brushes to detail alone, you can drop that down to under 50. Even if hints worked the way you think they do, you might be able to drop that down to 40. In the grand scheme of things, you may have just saved yourself a second off your compile time and that’s about it.

Less nodes does not mean better performance.

Optimized portals to reduce visibility means better performance.

The two are very different concepts. The only nodes that you should be concerned about removing are the little tiny ones that are generated by small brush details by converting those brushes to detail.

(ACROBAT) #19

I always detail and caulk my maps. The problem lies with max_visability errors. This problem seems to be part of the -vis compile, and I assume too many leaf nodes so I need to reduce them.

Hints could merge nodes so long as _blocksize is disabled so the portal lines were never there in the first place

(kamikazee) #20

Again: they never merge nodes. They only form portals.