I well understand the limits and have gotten pretty good at optimizing stuff. What I was pointing out is this:

256 exceeds 256

Which it actually does not.

I'm guessing it has to do with counting that starts at zero instead of one. I probably have 257 models.

I've been adding one unnecessary func_wall off and on over the last several builds just to see how close I was to the limit.

I'll take one out now and the warning should go away.

Nevertheless, 256 is not more than 256

The good news is, I still have 5 or 6 models left to play with :) 

It's probably a counting issue and a bug of that message. The index would 0-255, the range of that is 256 items. So the model with index 256 would be one over the 0-255 range as it is actually the 257th model. 

negke: are you sure > 256 models loads in engines that don't support it? i remember having to remove bmodels from some maps like nesp09 because there were over 256 and it was crashing the engine. 

What I meant is that a map with exactly 256 unique models will still load despite the warning in Fitz and BJP. Anything above that number will cause a crash. 

It might load, but I suspect that you'd have problems with model 256. The limit is because vanilla quake sends the model value as a single byte over the network. If you try and send 256, the server's going to send 0 instead - and 0 is interpreted by the client as "no model". As long as you're happy with the last model only being visible in engines with higher model limits, you can have 256. 

the message is slightly buggy i think. The true limit is that a model with index >255 will break the network code on protocol 15 (you'll have some invisible entities.) So 256 models is okay, 257 is bad.

The bug in fitzquake is I used >=256 instead of >256 as my check for displaying that message. 

As we were talking about it in the thread of mfxsp6 and in others, i became more curious about it, and want to know more before i get this one in my maps. So i ask:

What is HOM exactly? What causes it? How do you fix it? 

it's the polygons that are not being rendered.

this happens if you have erroneous brushwork: too little trianlges, too many intersecting edges on one face, textures of various nature touching each other (water+sky or something). or just huge room with too complex geometry, bsp-vis compilers just can't cope and make erroneous polygons.

so just build clean and simple and with r_speeds in mind and you'll never get this hom thingy. 

It stands for Hall Of Mirrors. 

I don't know about other engines, but in Fitzquake if you set gl_clear 0 and noclip outside the map, there will be HOM everywhere that's empty space and you'll see why it's called "hall of mirrors". 

I had an idea about doing it on purpose using skipped textures. For that crazy 'down the rabbithole effect'.

Anyone:

Has that been done yet? I think it could work really well, maybe having chunks of other realms in weird positions as the player moves through some sort of rift. I nearly had a go on my last release. 

for me HOM as an effect is ruined by it's associations with errors, problems, bad mapping, whatever 

might be interesting as a breaking the fourth wall type of map 

Okay, I've been having to go very slow with making changes. Basically I'll make a few changes, only in one particular area, then copy the map over to my fast computer and BSP it. If the difference in marksurfaces is reasonable, I keep going, otherwise I start hitting the undo button.

Today I cloned a light fixture, not very big and kind of detailed, made from about 12 or 13 relatively small brushes. Connects to the wall at a 16x16 section of brush.

Copied the map and ran TxQBSP. When I saw the marksurfaces number I almost fell out of my chair. The increase was from 32,258 to over 33,000 !?!

Started thinking, well that light fixture didn't really look too good in the map, and there's two others exactly the same, I'll delete them all and maybe get a reduction of a thousand or more marksurfaces. Wrong.

New marksurfaces was only about 100 less, which is probably pretty close to how many surfaces there actually were on the two fixtures.

I'll take what I can get, back to mapping. 

I worked at trying to reduce marksurfaces all day yesterday. It seemed like every time I simplified brushwork, the marksurfaces went up. I remembered negke's comment about rebb's modified txqbsp, so I downloaded that and gave it a shot. Magic.

Using the -forcegoodtree switch I got an immediate reduction from 32,266 to 31,763 with no other changes. That's some breathing room. Which is good because I had more stuff to add that was absolutely necessary.

I added another small room with an elevator and an arched doorway. I recompiled the map and... more magic. Marksurfaces went down again, by over 250!

I'm now at 31,507 and I think my marksurfaces problems may be over because there's not much more stuff that needs to be added.

I did a full compile and played it through to the end, looking for any bsp errors the whole time and didn't see any problems at all. 

So pumped to play this! 

 

It's still very much an experimental switch, but it does help with marksurface counts - the only side-effect seems to be a somewhat less efficient PVS in some cases.
A few well placed hint brushes should help if needed though.

It would be nice if someone with a much better insight than me into the dos and don'ts of BSP creation could take a peek at the code ( it's a super tiny change in qbsp.c ) and confirm/deny if this is actually a horrible idea ;) 

Do guys know if and what version of the programs QME and WORLDCRAFT may be used in commercial works ?

tHaNk in advance 

I've done a few practical experiments today to test how BSP responds to the order of the brushes in a map, so I'll write up and post all about that later - and hopefully explain why adding a brush can reduce the marksurfaces. For now, a bit of reassurance for rebb.

Once the compiler has created a list of surfaces from all the brushes in the map, it has to decide which one to compile next. It has two methods of choosing the next surface to split along, which we will call "fast" and "slow".

The slow way is easiest to explain. It tests every surface in the list, and checks exactly how many splits will be made. It then chooses the surface which will create the fewest splits.

The fast way is more complex conceptually, but quicker to compute. The engine looks through the list of remaining surfaces to find the ones which are axis-aligned. Of these, it chooses the one which best splits the area of the map into two evenly sized halves. If there are no axis-aligned surfaces, it just takes the first remaining surface.

The old rule for the bsp tool was to use the slow way for the visible surfaces, on the grounds that reducing visible surfaces matters. For the clipping hulls the fast way was chosen, either to save compile time or to make a more balanced bsp tree, not sure. However, once you're running up against the marksurface limit, then minimising the number of splits in clipping hulls suddenly has value. This is where rebb's modification pays off, as it applies the slow way everywhere.

Fun little idea which has seems to hold up from all that above(bear in mind I'm not that knowledgable on bsp stuff): If you've got big chunks of map with trisoup walls, maybe a cave...if you build some nice axis-aligned brushes to contain the cave walls, even ones which will eventually be clipped away, that ought to improve the compilation in the "fast" phases of compilation. Those brushes should be compiled early, and act like proto-hint brushes.

So coming soon - why all that minimising splits stuff is not what it sounds like. And how adding brushes can reduce splits! 

What if I want to put an enemy into my map (I am making a Quake 1 map) that doesn't appear (or "spawn") until the player walks over or activates some kind of trigger? 

Make a box room in your map, put monsters inside it. Over each monster make a brush entity 'trigger_teleport' and set a 'target' key on that entity with a value of 'Jeffrey' (or whatever). Give it a 'targetname' of something like 'triggerJeffrey'.

In your map make a point entity 'info_teleport_destination' where you want the monster to 'spawn', and call it 'Jeffrey'.

Make a brush entity where you want the player to trigger the spawning. Make it a 'trigger_once' entity. Give it a 'target' key with a value of 'triggerJeffrey'.

Now when the player touches the trigger_once entity, the teleporter in the hidden box room with teleport the monster to the info_teleport_destination. :)

If you are using the Quoth mod, just put the monster where you want it to spawn, give the monster a 'targetname' of 'Jeffrey', and check the 'delayspawn' flag for that entity. Now you can target the monster with a trigger_once brush entity and it will spawn when triggered.

:D :D :D 

Thanks for the help I will try that out!

However, there is one thing I was wondering in regards to the editor I am using (NetRadiant). When I go to "file" there are 2 options I am interested in know what mean. They are "save selected" and "save region". What do those do? Can I save only selected parts of the map or something? 

So here's part II of the weird and wonderful world of BSP Algorithm weirdness.
http://tomeofpreach.wordpress.com/2013/05/31/greedy-algorithms-and-bsp/

If you already know about Greedy Algorithms you can skim through this as it won't teach you much that's new. I hope that it will answer that burning question of how deleting brushes can increase marksurfaces - and please let me know if you are curious but part of the article was incomprehensible! 

A little func_ bonus content from that blog post. I tried some very simple experiments into how the order of brushes in the map file affects the BSP output. It's easy to replicate, just create a single 6 brush box, with a 7th cube floating inside(texture this one differently so you can recognise it). Export the map, and use a text editor to cut & paste the floating brush entry up and down the brush order - you can create 7 different map files in this way.

I then tried compiling all 7 maps with Rebb's compiler, first without the new switch. In this case, there actually was a small change in the number of markfaces: when the floating box was moved high enough in the map file, the number of marksurfaces fell from 193 to 191. Yup, that's a 1% saving!.

When I repeated the compilation with -forcegoodtree turned on, the marksurfaces held at 177 for all 7 map files, but that's a 9% saving over the earlier worst map. Seeing no variation does not seem surprising after the last post, where we saw that the "slow" method considers all brushes at once. But there were variations in other quantities like edges and clipnodes. How?

Well, I can think of two possible explanations. One is that these other quantities depend on some other part of the compiler we haven't considered, and bit that is sensitive to order of brushes. I think the more likely explanation is that even when always applying the "slow" method there are still occasional "ties" where two splits look as good as each other, and the compiler picks one solely on order in the map file.

This is consistent with the observation that all the faces in our test are axis-aligned, so we don't ever test the code in the "fast" method which compiles brushes strictly in order. It appears that the variations in the former compilations were only due to ties being broken by brush order. The fast way appears to generate more ties than the slow way (which is believable from the code), and these ties might result in greater variation (an interesting result).