average leafs visible: 593
max leafs visible: 2546 near (-288 224 704)
c_chains: 2003978043
visdatasize: 1058 kb compressed from 4668 kb

Elapsed time: 63h 35m
State time: 13:42

G:\Bsp\Bsp96b\Quake\Maps\pause
Press any key to continue...


What are c_chains 'cause that looks an awfully large number? What is State time? 

Just saw this at I3D: it's possible to have Gtk- and NetRadiant display the actual models for entities instead of the colored boxes. You need to edit the entities.ent file and add the model path to each entry, e.g. model="progs/player.mdl". They are loaded from the pak file, but are displayed unskinned (unless, I suppose, you extract the skin somewhere). The big problem is that only the model is shown, not the bounding box, which makes correct entity placement unnecessarily awkward. 

I had the same with my map.

Awfull lot of vising time, but I gave up at 67houres.
Recompiling some real small brushes to func_wall made it up to 8 houres.
For vising it takes too long.
My example

average leafs visible: 389
max leafs visible: 1544 near (-352 -152 -158)
c_chains: 1540051406
visdatasize: 668 kb compressed from 3718 kb

Elapsed time : 8h 58m
Session time : 8h 59m
State time : 1h 43m

I don't know for state time.
I don't think it are the c_chains, more some queer effect of brushes.
Try hiding extensive places with a big cube. 

Try comparing the bsp limits...


18087 planes 361740
65325 vertexes 783900
29085 nodes 698040
1743 texinfo 69720
56641 faces 1132820
58573 clipnodes 468584
15487 leafs 433636
64691 marksurfaces 129382
236371 surfedges 945484
127066 edges 508264
447 models 28608
96 textures 2493028
lightdata 1639628
visdata 863654
entdata 193675

vertices, clipnodes, faces and marksurfaces are usually the ones to max out first, but sometimes nodes can too. it depends on how you map.

in most (all?) modern engines like fitzquake, the limit for vertices, clipnodes, faces and marksurfaces is 65536.
limit for nodes is 32768.

 

Oh, I am not concerned about limits. And 63 hours vis time is not a problem: I just start the computer, shut the door (noisey fan) and take a peek each night before I go to bed. I just wondered what c_chains were.

No, the map is fine, plays fine, looks fine; and I only use FitzQ so going over a few limits is fine. 

RickyT23 posted a link to BSP editor. Anyone use it? Can it do things better than Hammer?
I tried it out for a few minutes (lots of buttons). Is it worth learning? 

I've used it for many years and never found anything better (but I did stop looking once I had used BspEditor). It is worth learning but use the tutorials and read all the notes because although it has a general Microsoft look and feel, it is not intuitive.

I use version 96B because later versions omitted support for Tony Brownlow's complier routines, and I use that program call to run my own compiler. However, the later versions do have some good additional facilities, so if I was starting again, I would have used the latest version automatically and never have know about the support for Brownlow.

Nevertheless, the built in batch file processes work just as well except that you have to write additional routines to make use of all the features of later compilers.

I have never understood why more people did not latch on to it? 

Screenie showing models in the 3D view complete with bounding box (shambler and torch visible)

http://i.imgur.com/GTHgc.jpg 

I'll try it out. Is it possible to have dialog boxes similar to Gimps "dockable dialogs" (boxes outside of the main window). That would be great for editing with 2 monitors. Any editors do that? I think it would be great to have the visual representation on one monitor the 4 views and the nuts and bolts entities, textures... on the other. 

What are efrags and should I be concerned if my map goes over the limit? Fitzquake seems ok with it and gives me a warning, but the warning appears after the map has loaded instead of before like the surf limits etc. 

"Too many efrags!"

This console warning is normally caused by having entities (typically torches) too close to or
even partly inside solid walls. Another possibility is too many (or too far apart) brushes that
are included in one brush entity. EFrags means Entity Fragments. Enhanced Win/GLQuake has higher limits. 

Thanks for that. I should have checked the compiler tips, since it was helpful last time and I'm assuming that's where you found that info. Sorry for being lazy :) 

It's indeed 'fragmented' entities like when you put all details in a room in a single func. The efrags count increases especially fast when doing this with func_illusionaries. Use devstats to keep track of current number.
Also note that clients handle efrags differently - older ones are usually more picky about it than e.g. Fitzquake and may constantly spam the console if the limit is exceeded. 

I always place torches 4 units inside the walls because I don't like the look of 'floating' torches, which is what you get by placing the torch's bounding-box flush to a wall.

My current map has hundreds of torches placed like this and does not report the efrag error.

Mind you, I do get:-
33744 marksurfaces
8808 signon buffer
64 lightmaps
1257 byte packet
343 visedict

at map loading, and in game at one point I get:-

36 blights
601 edicts

...but it plays fine :) 

I don't think the torches-in-wall explanation is correct anyway. Best torch placement is where the origin of the torch is 2-4 units away from the wall, yeah. Certain areas may require to set the light level of the actual torch entity to 1, and use a point light several units in front of it. There's absolutely no reason to have floating torches or flames in a map - even through there are editors that only show them as boxes, it's all just the laziness of some mappers not to place them properly.

Mike, don't be lazy yourself and go optimize the map for vanilla limits. With those marksurfaces and edicts counts, it looks very possible to do that. 

I'm pretty hazy on the exact working of efrags but I can see they are about entities straddling multiple leaves in the bsp tree. I wonder if tweaking the torch model to have a 4 unit offset would avoid the problem. On the one hand that would fix it if efrags were generated by entity bounding boxes crossing leaf boundaries. On the other hand, the efrag code seems to be in the rendering portion of the engine so maybe it's the model bounds rather than the entity bounds which matter. In that case moving the model instead of the entity does exactly nothing... 

I can confirm it is the model bbox not the ent bbox which counts. Please disregard that suggestion. 

"Don't be lazy", well, as I am sure you know, it is not a case of being lazy; it is a case of mapping for my pleasure, not other peoples. If you ever see this map, you will understand why it is not meant for vanilla Quake, and will not be worth bringing inside the original limits. The original map was over 20,000 brushes with 700 monsters, and covered the full 4096 x 4096 area. I had already cut it down and released FMB_BDG a few years ago and what I have left is the balance.

Besides which, weren't the compilers and engines enhanced just so we could 'break' the limits? Otherwise, there was no point!

Anyway, don't worry, I know what you mean ;) 

~690 at the moment, and I have a lot of large funcs. I can probably reduce them a bit as I've nearly finished the map now, but I wonder if I'll be able to reduce them enough. I'll do some tests tonight to remove the largest func_illusionaries.

Aside from that, it's just clipnodes and marksurfs that are over. No way in hell I can lower marksurfs enough to bring it under the limit without spending a massive amount of time removing detail, but clipnodes should be easy enough, since there are lots of arches and small details in the map.

God I'll be glad when this pos map is finally finished and I can forget about it at last :/ 

I think I recall seeing marksurfaces actually DROP when converting func_s to world geometry. 

Not too hard to imagine if the func and the world intersect or overlap, as both sets of brushes would get faces culled, which might offset any extra splits. 

anyone know if a trigger once can start disabled, be triggered by another entity to become active, then trigger normally by the player? 

But we had that in the RMQ progs 

no, but:
http://www.celephais.net/board/view_thread.php?id=4&start=4469&end=4469

(trigger_changelevel does have that functionality though; set 'startdisabled' to '1') 

terrible idea but it might work