Thanks, Madfox. 

I'm currently working on a big project (i.e Doom3 Hell level remake), and I exceeded this evening the maximum marksurface value (i.e message is WARNING: Marksurfaces 34803 exceed normal engine max 32767 , with aguirRe's TxQBSP v1.12). I'm able to load the map with aguirRe's engine, but it is choppy as Hell with FitzQuake...
I just would like to know if there's something I can do either to dicrease Marksurfaces in a map... without removing any poly (and it is not yet finished....), either if there's something to do with engine options... or if I have to restrict the map to aguiRre's engine ?
Any advices ? 

if you're planning to expand the map further, you likely have a problem. you can try to lower marksurfaces by turning some structures into funcs, moving them away from adjacent brushes, or reducing faces by merging them into individual textures. 

According to other mappers, marksurfaces might go up and down while adding more brushes, so you could try continue working on it and see if they drop.

Furthermore, if Fitz is just choppy, I doubt that it's the marksurfs that's causing it (normally it would crash if the marksurfs were exceeded). You could also check with e.g. JoeQuake.

Try upping heapsize instead and see if that helps, e.g. 48-64MB. 

Sometimes they go up other times they go down.
I'm having trouble with marksurfaces as well on the map I have in beta.
I have found that Fitzq can handle marksurfaces up to around 38000 and then it crashes! Anything under this seems to be safe although it's over the max. 

...if you can build it over the limit Fitz will handle it to where Hrimfaxi indicates. But, JPL if this thing is as big as I think then you might seriously consider chopping it up at some logical point. The only way I could get qte2m3 to work in the end was lop off everything past the GK door and turn that into a separate "end" level...that and simplify some of the natural rock formations in the main map (that was painful =/ but necessary)

Good luck with it either way. 

I am currently having problems with the number of marksurfs in my large map, but fitzquake still loads it. The thing you need to be careful of in fitz is that when marksurfs, clipnodes etc. are exceeded, memory gets randomly overwritten. I don't know exactly how random this is, because at the moment there are no noticeable problems with my map. However, when I had too many clipnodes as well as marksurfs, the last func entities that I created were becoming nonsolid - I guess this is just because there were too many clipnodes to fit into memory and the solid entities were the last things being loaded so they became nonsolid.

I have had fitz crash because of exceeded maxsufs before, but oddly it doesn't crash as soon as you pass the limit. Anyone know why? 

Thanks a lot for all the advices... I think I will continue my work as I just need one more corridor and a room plus the final area to finish the map... Maybe it will pass with a fullvis process... In anyway, I already have an idea where to split the map... I'll see that later when all the design will be done. Maybe FitzQuake will be able to load it without choppy thing... I don't know what happened, but it occurs after the first monster spawn... pretty weird... I have to re-test it to see if the problem is persistent....
Thanks a lot again ;) 

The limit *is* 32768, any engine that's not fixed to handle a higher amount will behave unpredictably due to memory being trashed. Depending on how that memory was/is being used, you'll get different results.

JPL: did higher heapsize help the choppyness? 

I still not tested it yet... but I think I've always a -heapsize 48000 added in the command line.. (note I'm not usre of the value ;P ...) 

Well, having -heapsize 48000 option doesn't help much with FitzQuake: the result is that i need to cut the map in two pieces.... Not a big deal....
Anyway, I already said it but, thanks a lot for all the help above :) 

C:\Program Files\worldcraft\Q1Tools>txqbsp -quiet -numpercent capacitance
TxQBSP 1.11 -- Modified by Bengt Jardrup

Inputfile: capacitance.map

Building hulls sequentially...
Processing hull 0...
100%
100%
WARNING: Reached occupant at (512 -1240 8), light
Simplifying ... Leak file written to capacitance.pts
100%
Processing hull 1...
100%
100%
WARNING: Reached occupant at (64 -256 32), info_player_start
Processing hull 2...
100%
100%

34 warnings

So, yes, my map leaks. I don't know why.

The map is completely sealed. I do have complex brushwork, as in 3/4 of a pipe wrapped around curved corners. Could this type of manipulation cause a map to leak, even if it is completely sealed in the editor? 

If you are using Worldcraft, the answer is yes. The most likely problem you are likely to face regarding leaking maps and worldcraft is that you have used vertex manipulation to create an invalid brush (i.e. a non-convex volume, or non-planar face). When you try to compile a map with such a problem, the brush shape will be changed by the compiler so that it is convex, which can result in leaks appearing.

You can check for invalid solids by hitting alt-p (should also be in the map->check from problems menu), which will give you a list of problems with your map. DO NOT let Worldcraft auto-fix your problems, as it can sometimes make things worse by deleting things that only required minor modification. The go to error option is, however, completely safe, and is VERY useful for tracking down solid entities that don't have any brushes (if you merge two solid ents, one always remains and causes problems, but can be selected by checking for problems and deleting it manually.)

There are other reasons that a leak might occur, but I think the above mentioned vertex manipulator abuse is the most likely problem. Try checking it out.

By the way, if you add a lot of fields manually to entities rather than modifying your FGD files to include them, Worldcraft's problem checker will report the key/value pair as being an error ("entity has unused key/values") These errors can be ignored completely. 

...Ionous is mapping again! I thought we'd lost you buddy, welcome back. 

If you can't sort it out, send me the zipped map+wad and I'll check it out. 

i got 311 on mine :\ and i dont have leaks to... 

One thing I found with terrain mapping (lots of wedge brushes) is that if it's a long thin wedge then it won't break, but usually breaks any thicker wedges nearby so that the leak goes straight through a solid brush. The only decent way to het round this is avoid thin wedges, or else have a big block inside your terrains, usually alot of em, though that's a ugly and wasteful fix.

Other than that turn all pillar / pipe / cable flanges into func_wall or else leave them 2 units from touching the wall or floor. The second can still produce vis crashes if you have lots of them but the first is completely safe, as long as you don't breach edicts.

As than says use the check for problems function, but don't auto-fix. If you do have invalid brushes you may not be able to fix them without creating from scratch, though that depends on how complex they are.

Can't think of much else (I assume you know about the pointfile command - type it ingame at the console and it's show a particle line pointing at the precise location of the leak).

Hope that helps. 

Yeah, i am using Worldcraft.

Than:
It appears i have been caught. I was using the method outlined in CZG's curve tutorial to bend a 3/4 piece of hollow pipe (roughly 256 in diamter, with 32 thick edges). When using this method, i found that the edges weren't aligning on the vertices with exact precision, so i using vertex manipulation to get it right. I then got lazy and started doing it purely with vertex manipulation. I'm guessing that might be the problem part.
I have used the "problems" feature, and it claims that the map is without error. It once had errors, but i fixed them manually, and then worldcraft seemed to like it enough to not give me an error.

Distrans:
Thanks, it's been a long time, my mapper's block had gotten so bad that i just decided to stop for like 6 months. Things seem to be going good now. Hopefully Travail isn't giving you splitting migraines.

aguirRe:
Thanks for the offer. I'm not going to be able to touch Worldcraft again until maybe tomorrow, most likely Friday, so if i still can't make the bad leaks go away i'll drop you a line.

ijed:
I wasn't specific enough in my post, but the "pipe" i spoke of is actually the hallway, so i'm not sure if making something like that would work as a function_wall. I may be mistaken, but i'm not sure if i could use a function_wall as a border to the void.
What you said about terrian is interesting though, since i do plan to use a good amount of terrain in my map. What do you mean by breaking brushes, wedges and leaks through solid brushes? I don't quite understand the explanation.

Thanks for the help all. 

Nope, you can't use a func_ to stop void ;)

The pipe thing (I use the czg method as well) is awkward, you've got to figure out the system of thinking in base 8 and even now I end up redoing it a few times to get it right for a corridor or whatever. I wouldn't recommend vertex manipulation for this - it'll drive you up the wall.

Also, you can just make a blocky corridor when seen from outside, then make it round on the inside with the 12 sided cylinder and double-wedge corner piece. Since the outside is void and not world nobody'll see it.

By blocking off broken brushes I meant putting a quad brush inside your terrain, sealing any hole it has from the void - but this is a big waste and will fuck vis.

When making terrain copy and paste a single unmodified wedge as many times as you'll need it then vertex adjust each piece seperately - WC tends to create errors when copying multiples of these. Either tiny misalignments (leaks) or a slight lip in the ground, so that you hit an invisible wall in the game when walking in a certain direction and then can't get unstuck. 

One other thing, probably something else you already know, but I didn't figure this out until a long time of using WC - you can move the camera (not just rotate it) in the 3d view with right click.

If that helps. 

Thanks for the heads up on the camera deal. I always found it annoying that the camera use was limited. That makes it better to use. 

they are great.

In addition to being able to move the camera around in both 2d and 3d views, you can create multiple camera views per map by holding shift and dragging in the 2d view when in camera mode. There might be a key to cycle camera views, but I don't know it if there is. Deleting a camera will return you to the last one create before that, or just the default camera (which doesn't have any icon in the 2d views).

In addition to the mouse controls, you can also move the camera around with d/c (zoom in, out - also works in 2d views) and s/f (roll, not very useful). Also, if you learn the shortcuts to switch between camera and other modes, the fact that controlling the camera requires you to be in camera mode (aside from moving it via the keys) won't slow you down anymore. 

iirc, it's page up & page down to cycle through cameras...been a while for me though 

pgup and pgdown work, but only in camera mode. In selection mode they seem to do something weird, like add the previous selection to the current one. Maybe you can use it to get the last selection if you lose the selection.

...hmm, just tried it, and in selection mode pgup and pgdown have very odd behaviour. This is what it says in the WC help:

PgUp - previous selection in "hit" list
PgDn - next selection in "hit" list

Whatever the fuck that means. 

I think that many WC and Hammer users should spend some time reading the users guide included in the program. It is an interesting read. There are many tips and pictures. All the features mentioned above are described throughoutly.
Here is a section from Hammer manual about the cameras:


Using Cameras

To take advantage of the 3D view, you need to be able to place cameras. Cameras determine your vantage point(s). Hammer provides you with precise control over the camera movements in your map.

A camera in Hammer (as displayed in the 2D views) consists of two parts: the eye, and the viewing angle, which is represented by a line extending out from the eye. The length of the line that represents the viewing angle is not important, though it can help you aim the camera exactly at an object.

While it is possible to move a single camera all over the map each time you need to look at something new in the 3D window, it is more convenient to have easy access to multiple cameras placed throughout the map. Hammer allows you to easily cycle through multiple cameras by pressing PageUp and PageDown.

Camera Placement
Placing cameras in Hammer is extremely simple. First, switch to Camera mode by pressing Shift+C, then hold Shift and with the left mouse button, click-drag a line in one of the 2D views. This will create a thin red line with a large dot at one end. The dot is the camera's position, and this is where the 3D camera view will originate. The red line is the camera's viewing angle. You can adjust either end of the line to change the view. Follow the above steps to create as many cameras in your level as you need.

Note: There are a number of options available to you when using multiple cameras. You must have the Camera tool selected to take advantage of these:

PageUp: cycle up to the next camera position
PageDn: cycle down to the last camera position
Delete: delete the current camera position
Shift: hold shift and click-drag with the left mouse button to create a new camera.

Tip: While in camera mode, you can adjust the camera position by moving the eye or viewing angle in any of the 2d windows.

Mouselook/NoClip Style Movement
Version 2.1 of Hammer introduced a new style of 3D View movement called mouselook movement. It is designed to be the same as when you are in the game and walking around with +mlook (mouselook) and the NoClip cheat both turned on. It can be enabled or disabled by pressing (lowercase) z.

Moving your mouse around will change the player's direction of focus, while W and S control forward and backward movement, and A and D control sided to side (left and right strafing) movement.

The old style keyboard shortcuts (listed below) still work. You can disable this new movement style by going into the 3D View options and disabling use mouselook navigation.

Keyboard Shortcuts
There are a number of keyboard shortcuts that you can use to quickly maneuver through the 3D view without switching to the Camera tool.

While holding the spacebar:

holding the left mouse button allows you to rotate your angle of view in any direction, while the viewing point remains stationary.

holding the right mouse button will allow you to move left, right, up, and down while keeping the viewing angle constant.

holding the left and right buttons and moving the mouse causes the view to strafe forward, backward, right, and left. (note that this makes the following behavior redundant).

While holding the spacebar and Shift:

the left mouse button acts the same as above.

the right mouse button allows you to move forward and backward, as well as from side to side.