does darkplaces's "mcache" command print the list of models like QS's?
The ones with a "*" prefix are submodels of the main bsp, i.e. func_ stuff in the main map. The other things in the list will be the unique mdl's and sprites precache by the map.. so e.g. if you remove all monsters that use a certain mdl, it should free up a slot in the list.

Can you merge any breakables that are close together?

If you use any func_illusionary / func_wall that don't need any scripted behaviour, switch to func_detail_illusionary / func_detail_wall, which don't use up models. 

mcache isn't a command that works in DP.

I merged a lot of breakables, saved several hundred entries. I'll see how I go getting through the rest of the map, there are a lot of func_illusionary brushes that i could convert if need be. 

Several hundred!??

You could potentially combine all func_illusionaries into 1....except then they would probably always be drawn instead of culled. 

Looking forward to seeing all these breakables!

You could potentially combine all func_illusionaries into 1....except then they would probably always be drawn instead of culled.
func_detail_illusionary are pretty much perfect for this, the only downside is they tend to increase leaf/node count, because they're part of the main bsp just like func_detail. It's only really a problem if you're trying to fit in standard BSP format and are near the limit.

func_detail_illusionary will also have the best rendering performance (as they're identical to other world polys), and 100 separate func_illusionary's the slowest. 

I did look into func_detail_illusionary but it casts a shadow, which makes it unusable in a few of my cases for this map.

Unfortunately the breakables aren't that interesting - just crates, like I did for my Noir Jam map. Interestingly despite all the breakables the mcache for that map was <1000. 

Ah, right.. for it to not cast shadows you need to be on the latest version of my light tool. I'm still working on the bug you reported, sorry it's taking so long 

Wait so do brush entities not count towards the limits for verts, tris, etc.?

Is the limit per "model"? 

brush entities do count towards the overall .bsp file limit, but func_wall vs func_detail will have different resource usage because the func_detail has to slice up the map geometry that it is overlapping (leafs/nodes, faces). 

On my current mapping adventure I'm creating an outdoor map with terrain-esque features. I find that in Quakespasm and Winquake I get stuck when walking over that edge:

http://maikmerten.de/base1/terrainstuck.jpg

All fine in FTE and Darkplaces. Map compiled with the awesome ericw-tools. All brush vertices on integer coordinates.

I'm pretty sure a random vertex manipulation should resolve the issue and I guess this is just a side-effect of how Quake handles collision (I think FTE and DP basically have their own ways of doing things there).

Is there a lazy way to resolve such issues reliably other than pushing vertices until things are resolved?

BSP and .map source: http://maikmerten.de/base1/terrainstuck.zip 

It can even happen out of nowhere after a compiling in areas where nothing has been changed since several compilings before.

Move some vertex around a bit and that will disappear. 

Yeah, I already fixed it - once you discover such problems a workaround does seem to be mostly trivial. Just wondered if this is an indication that I'm doing something wrong or if this is just some charming oddity of Quake in general. Looks like it's the latter and I shall embrace the madness Quake awakens in our hearts and minds.

Glad I'm testing with multiple engines, though ;-) 

If one is mapping using trenchbroom on an unsaved map and TB crashes, is the map lost?? 

Ive found them hiding in C:/users/MYNAME.


"Trenchbroom-crash.map" 

 

this is just some charming oddity of Quake in general

Yes, and that's why there is not much terrain in Quake custom maps, and one of the reasons there is none on the official maps. 

niccce. happy to help, drow! 

I'm using ericw-tools to compile my maps but the lightmaps always look like shit. They are too blurry. Is there a way of increasing the lightmap resolution? 

you can do it on a per entity basis by adding an '_lmscale' field set to eg 0.25
on the command line you can use '-lmscale 4' with ericw's light util.
I'd also recommend the '-bspx' light util argument, if only so that you don't need the external lits.

alternatively compile it as a q3 bsp via q3map2 (using q1 ents still so that mods don't break). A _lightmapscale field set to 0.25 or so for that, I believe. this'll give you a few more options that are not available with q1 bsps.

that's the theory, anyway. note that each of these have different results when viewed in other engines. 

There's a good chance I inadvertently broke one of _lmscale/-lmscale/-bspx since I haven't tested them since Spike contributed the features, but a ton of other things have changed since then. If that's the case, there are old releases available at: https://github.com/ericwa/ericw-tools/releases and feel free to file a bug.

Anyway I would +1 using q3bsp. AFAIK all of the _lmscale/-lmscale/-bspx options will produce a q1bsp that only looks right in FTEQW. 

iirc the per-entity _lmscale + -bspx will generate redundant data for engines that don't support it.
obviously other engines will get inferior lighting, but it should at least otherwise work (unless you use -novanilla for smaller bsp sizes, in which case other engines will glitch, but shouldn't crash).

I really ought to add this stuff to QSS too, same as many other things. 

QSS now supports lmscale too, in case anyone cares. 

Won't you lose lightstyles by going q3bsp? I always considered that a feature-gap that might have a sound technical explanation (*) but just robs single-player maps of a simple way to make things appear more dynamic and dramatic.


(*): I guess lightstyles just don't go well with the light-grid, but then I'm not a fan of that anyway because its size just balloons quickly as you extend map dimensions unless you lower the resolution so much you could just as well sample from the lightmap. 

the rbsp variant (and derivatives like fbsp) supports lightstyles (4 per surface, like quake).
and yes, 4 styles per lightgrid node too (it uses some compression scheme).
FTE supports them (if you've custom shaders then lightmap passes need to be first due to format weirdness), but dp doesn't.

(side note: it might be nice to calculate model lighting for the centre of each leaf, and interpolate between those, using surface data in place of neighbouring solid ones.)

even with q3bsp itself, you can get lightstyles with rtlights.
alternatively you can get quite creative with custom shaders.