Max Clipnodes limit 32767

Discuss the construction of maps and the tools to create maps for 3D games.
Post Reply
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Max Clipnodes limit 32767

Post by ajay »

Just had this error hit me in my earthQUAKE large city map, after taking out a 'solid' building and replacing with a hollow accessible one. Is this an error I'm only going to fix by simplifying the map or are there other solutions (I'm certain there's no leak btw)?
I'm trying out filling empty space with clip brushes, but I have my suspicions that a combination of not-great-mapping and a very large, at times complicated map have finally exceeded Quake. :(


***EDIT***
Scratch the above (for the time being anyway) filling the space has worked for now... I've a feeling I may run into it again tho'....
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Post by metlslime »

if there are any ares the player can't go, fill those areas with a giant clip brush. That will reduce clipnodes.

EDIT: I see you already did this. Well, it's a good idea, don't be hesitant about it :)
necros
Posts: 77
Joined: Thu Dec 16, 2004 10:32 pm

Post by necros »

not just filling in large spaces, but, basically any place the player can't move into.

let's say you had a computer screen or a light strip recessed into the wall. if you put clip brushes to cover up the holes, that will reduce clipnodes as well.
or like, if you had a table, you could fill up the bottom of the table, between the legs, with clip brushes.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Post by qbism »

fitzquake can >32k with mclipnode_t
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Post by metlslime »

necros wrote:let's say you had a computer screen or a light strip recessed into the wall. if you put clip brushes to cover up the holes, that will reduce clipnodes as well.
or like, if you had a table, you could fill up the bottom of the table, between the legs, with clip brushes.
I'm actually not sure this helps, qbsp should automatically fill in spaces that the player bbox can't fit into. But i haven't tested this empirically to see if clipnodes go down.
necros
Posts: 77
Joined: Thu Dec 16, 2004 10:32 pm

Post by necros »

i've never done any hard testing on it, but i have found i can squeeze a fair amount of clipnodes from just filling in little gaps and such. places you can't move into anyway.

also, this just occured to me, but if you have a func_illusionary with a lot of 'spiky' bits, you should probably cover the entire thing with a clip brush.
since illusionaries aren't solid, it doesn't impact anything in the engine, but the compiler doesn't know anything about func_illusionary, so will still create clipnodes for them.
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Post by ajay »

Thanks for your replies everyone. All being considered and tried...
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Post by ajay »

The problem keeps re-occurring and I keep fixing it by adding more clip brushes in empty spaces. I think that, with much more to add in the map, I'm going to run out of space to fill, and therefore my thoughts are:

- it's not a problem that appears to bother the engines; FQ, DP and DQ all run the map with no problems, so it's problem only during compiling (the map fails in most other engines for other reasons, so I'm just worried about keeping it running in those 3 anyway)
- it's an error flagged up in QBSP, so is there a QBSP that ignores it or has a (MUCH, hopefully) higher clipnode tolerance? (I'm using: "TreeQBSP v1.70 -- Modified by Bengt Jardrup")
- is it flagged in QBSP because of an assumed limit that engines would fail at? (Now no longer an issue for newer engines)
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

Unfortunately you'll never get more than ~64k clipnodes from Q1 BSP as clipnode numbers as stored as 16-bit short integers in the BSP file itself. The format also needs negative numbers to be stored, so there is a further restriction that the highest positive clipnode number minus the lowest negative can't exceed ~64k.

This is a Q1 BSP format limitation, nothing really to do with the engine you're using. There are loads others (vertexes is particularly troublesome).

I'm actually surprised that more engines haven't gone down the high capacity route; I would have thought that it should be reasonably common by now.

FTE would probably run it too, but then again I have a feeling that FTE would probably run Pong maps if you tried. :mrgreen:
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Post by metlslime »

ajay wrote:- it's an error flagged up in QBSP, so is there a QBSP that ignores it or has a (MUCH, hopefully) higher clipnode tolerance? (I'm using: "TreeQBSP v1.70 -- Modified by Bengt Jardrup")
Use the -hilimit option to ignore that error.

http://user.tninet.se/~xir870k/readmetree.txt
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Post by ajay »

Thanks again. I've gone with the 2.05 version of TreeQBSP and it's compiled it with just a warning, rather than stopping with an error.

*Admission*
I hadn't realised there was a newer version until trying to run -hilimit and it not being supported, then read the readme.txt (above) and then downloaded the newer one.
Post Reply