Hi I was wondering if anyone had any information about if modern quake engines have any limitations with respect to brushes, vertices, entities etc...

I am trying to make a map but am getting a little carried away with it. I am worried that I am working on something that will never run because I've taken it too far or something. It's gonna be awhile before it's sealed up and am wondering if that time would be better spent simplifying the brushwork.

SS of map in editor:
http://i.imgur.com/riPcFnE.png

SS of map in game (from a few days ago:)
http://i.imgur.com/m128dD2.png 

https://quakewiki.org/wiki/Engine_Limits
and with BSP2 you can go with even higher limits 

Okay next question, is there a way to check if a map exceeds these limits without compiling? 

is there a way to check if a map exceeds these limits without compiling
no. pretty much all the limits are subject to qbsp's csg or bsp tree logic, which can even vary from one qbsp to the next.
While you could try guessing based upon brush count, quite often its what you did with them that counts.

For instance, if your map has no leaks then the outside part of your map can be completely cut away, the leafs are merged, the nodes are redundant, those faces can be discarded, etc - this significantly reduces the amount of data needed.
If you have a lot of surfaces all cutting through each other then you'll have noticably more nodes/clipnodes per brush. Stuff like that.

Do note that there's an unsigned variant/reinterpretation of the vanilla format which doubles the formats limits from 32k to 64k in various cases, which is incompatible with vanilla (hence how various engines claim various 64k limits where vanilla does not). Many qbsps will generate this without even realising it (although light+vis utils might then bug out if they're really old, depending on what you exceeded). 

So from what you say and what I've read, I understand that as long as I'm sensible with my brush work, seal the map, use updated tools and compile with BSP2 that I don't have much to worry about?? 

Don't use BSP2 from the start, switch to it only when you reach the first limit.
Check your bsp with bspinfo to get more precise data, but from screenshots you have posted, I think you're far from the first limit. 

 

You use tyrutils it will give an error once you exceed the limits. Then you can add "-bsp2" to the qbsp parameters. 

I'm in leak hell. Absolutely stumped :P

Using Tyrutils v15.4 & J.A.C.K editor

The map leaks through solid walls into the void. There are no entities outside the level. The map is sealed. I've meticulously checked everything. When I put giant brushes over half the map to leak hunt, the un-boxes part leaks, this repeats no matter where I put the brushes. I literally covered the entire level in giant brushes aside from the player start box and it still leaked.

Any ideas a very much appreciated :) 

Here's a brush from the map file
( 193.373 -320.665 600 ) ( 192.665 -321.373 600 ) ( 216 -343.293 600 ) COP1_2 [ 0.707093 -0.707121 0 -11.127 ] [ -0.707107 -0.707107 -0 -59.0101 ] 0 1.00098 0.999997
( 215.293 -344 632 ) ( 192.665 -321.373 632 ) ( 216 -343.293 632 ) COP1_2 [ 0.707114 -0.707099 0 -11.4788 ] [ -0.707107 -0.707107 -0 -59.01 ] 0 1 0.999997
( 216 -343.293 632 ) ( 216 -343.293 600 ) ( 215.293 -344 632 ) COP1_2 [ 0.707099 0.707114 -0 59.0142 ] [ -0 -0 -1 56 ] 0 0.999997 1
( 192.665 -321.373 632 ) ( 192.665 -321.373 600 ) ( 193.373 -320.665 632 ) COP1_2 [ 0.707099 0.707114 0 59.0139 ] [ 0 0 -1 56 ] 0 0.999997 1
( 215.293 -344 632 ) ( 215.293 -344 600 ) ( 192.665 -321.373 632 ) COP1_2 [ 0.707107 -0.707107 -0 -11.4797 ] [ -0 -0 -1 56 ] 0 1 1
( 193.373 -320.665 632 ) ( 193.373 -320.665 600 ) ( 216 -343.293 632 ) RUNE_A [ 0.707107 -0.707107 0 -11.4801 ] [ 0 -0 -1 24 ] 0 0.999999 1

Horray for guinea pigging new level editors 

In JACK you can free rotate a selection of vertices in vertex edit mode around a pivot point under your mouse cursor by right click -> dragging in the 2d view. Even if you go back and move the rotated verts back onto grid after the operation they will be off by a tiny amount, resulting in the crazy decimal points.

So : PSA - Don't use vertex free rotate mode! 

http://i.imgur.com/2qIIzYV.png

So, I recently converted my map from standard to valve 220 format, thanks to ericw's recent tool update. As nice as textures not "shearing" all of the time when you do weird and kinky things to your brushes is though, I find myself missing the nicer way that standard format seems to handle textures wrapped around curved brushes.

The image linked at the top of the post is an example of this - both are valve 220 brushes, but the left one has texturing from before I converted the map, and the other has had its textures freshly "reset" to no offset/rotation/scaling.

Does anyone have any tips for getting the sort of look that the brush on the left has for "new" brushes? I imagine it must be possible in the format still, but it obviously does not come naturally... 

Getting this error in Quakespazm. Solutions I've tried is using the find/replace feature in notepad to remove all water/sky textures from map, and also tied "-subdivide 256" on the Txqbsp command line. (without fully understanding what it does.) It still fails to load.

I'm beginning to think that the issue is architectural. i.e. too much visible to player or something. Could that be the case? The map on a fastvis was in the ballpark of 30+ megs which is something I've never seen before. And if thats the case, is there anything I can do to salvage the map?

in editor screenshot:
http://i.imgur.com/4b0xReO.png 

It's definitely not too much architectural detail, most likely bad texture alignment on a face.

My light tool used to print an error for this with the texture name and coordinates of the face to aid fixing it, but it looks like that message was broken at some point. I can take a look at the bsp if you want. 

I'm trying download DaZ's .fgd from post #18307, but I get the 404 error.
Where I get JACK-compatible .fgd for vanilla Quake and Ericw compilers? 

I had this error recently, you may have a brush somewhere with a texture that is either squished waaaaay to small or stretched waaaay to high.

I ended up pasting the map file into excel, using spaces to delimit the rows, then sorting by the last row to see the highest and lowest values.

I don't know what the exact limits are, but I would get rid of any texture that is scaled smaller than 0.1 or larger than 5. 

if you notice in the SS, that none of the textures are aligned, that is because I selected all and reset textures in an effort to solve a problem with texture scale that was causing BSP to fail.. It worked but loading the map would still crash the engine. "Bad Surface Extants." it says.

I managed to compile a "working" version of the map by placing a giant brush in the middle of it, effectively blocking view to the other side. It runs fine apparently in Quakespasm no problem but the map was targeted for quakeworld and in QW its a disaster.

QS SS: http://i.imgur.com/22j6yh3.png
QW SS: http://i.imgur.com/4QWcwXM.png

I thought that running a full vis overnight might solve the QW issues but when I woke up it still had 33 hrs to go. Also in QW it takes some time for it to load and you need the -mem 128 command line too.

It was a lot of fun putting this map together but find that working within the the perimeters of QBSP and engine (somewhat restrictive) capabilities to be an unforeseen challenge. I'm still compelled to work on it, but a lot of my focus will be on scaling it back, or salvaging the more clever brushwork (by my standards) for more sensible application.

I loved mapping for Quake back in the day and find that modern editors are so fluid and responsive that it's very easy to become drunk with power. 

Which compilers did you use - does this occur with bjptools_xt or tyrutils_ericw? 

TxQBSP 1.13 I want to experiment more with the existing compilers though. 

Make sure that your faces are all set to 'world' alignment, not 'face'. (P.S. world/face terms used by Worldcraft/JACK/Hammer and may not match terminology for your editor) 

is so similar to a map I was working on over a year ago it's crazy... it took me a second to realise it wasnt the same map. 

This link should work for the fgd https://www.dropbox.com/s/lv4r7tmcspcz2gt/quake4ericwTools.fgd?dl=0 

Big thanks for this.