large maps help

[ceriux]

so i wanted to see is how large of a map you could make using either DP or FTE since i'm pretty sure ive read somewhere that their map size limits had been raised.

however i seem to be having an issue. ive made this test map and have gotten some weird results. first when loading in it looks as if i hadnt closed part of the map (even though its fully enclosed.) but you can walk through this weird opening and this is what you get.



you can continue to walk through to the other side of the map. but this is obviously not what i was expecting.

have i just hit the limit? maybe i used the wrong compiling tools for an excessively large map? perhaps theres a command i need to launch the game with so its handled properly?

any help would be appreciated.

[frag.machine]

What network protocol is this engine using ? If it's standard Quake protocol (version 15 IIRC, just check in the console output when loading the map) it won't support coordinates values outside the -4095 to 4095 qu's range.

[Spike]

fte has some logic to extend coord sizes only if the map actually needs them.
this is auto-detected by checking if a map entity has an origin outside the +/- 4k range.
you can also force it with sv_bigcoords 0/1, if empty then it'll autodetect.
(using big coords results in eg ezquake or proquake failing to connect, so fte uses autodetection instead of just defaulting it to enabled).

dpp7 ALWAYS uses 'big coords', but if you've got dp configured to use protocol 15 or whatever then you'll get different results.

quakespasm can be configured to use protocol 999. this will also increase the map sizes (fte auto-forces the same protocol for nq clients when bigcoords are enabled).


the original protocol uses 13.3 fixed-point coords, giving 1/8th precision with +/- 4k range.
fte+dp both support floats for all coords (when configured to use extended protocols), which gives it the same range+precision as qc has.
999 has multiple options for extended precision, but you can generally assume that it supports maps at least 256 times the size.


the bsp29 format has a +/- 32k limit imposed by bounding boxes in the nodes+leafs.
DP ignores this completely, while FTE recalculates it if the map's geometry is also outside the +/- 32k limit.
2psb still has the same +/- 32k limit.
bsp2(the proper one) or q3bsp has no such limit.


finally, the far clip plane...
for fte, set gl_maxdist to 0 to use an infinite-depth projection matrix.
I don't remember the logic DP uses, I think its just infinite anyway.
quakespasm's gl_farclip defaults to 16k or something, but you should be able to boost it to fairly large numbers. beware of 16bit depth buffers.
also beware of skyboxes being drawn closer than the far clip plane limiting how far you can see.


note that if you have no entities outside the vanilla protocol's 4k boundaries, engines can still draw world geometry beyond that just fine, up to the map's boundary/far clip plane, if you like large vistas...


there may be other limits. I vaugely recall quakespasm having an issue with subdivisions if a sky/water surface is outside the +/- 9999 range. the qbsp is likely to also have limitations.

[ceriux]

yeah ... i just tried switching to bsp2 but the compiler doesnt seem to like whats going on...



i also tried a few of those commands which didnt seem to do anything. perhaps i should give up on a massive map..

[Spike]

you might have more luck with hmap

on the other hand, here's a fairly large pre-compiled map: https://github.com/plankatron/quakemash (in the release subdir). beware the load times.

I'd suggest the map mentioned in the following topic, but its download links are dead: viewtopic.php?f=1&t=172

[ceriux]

Thanks I'll check it out.

[ericw]

The qbsp in tyrutils-ericw should be ok up to at least +-32k units: https://github.com/ericwa/tyrutils-ericw/releases
I can easily raise the limit further, as it's pretty much just one constant in qbsp (BOGUS_RANGE, I currently have it at 65536)
As spike said, hmap2 should also be good for large maps, its BOGUS_RANGE is set to 10^9.

[ceriux]

so hmap2 seemed to do the job. however the limits are still too limited lol thanks for everyones help.
to do what i wanted id need a map at least 4x the size of whats available.

unless its just a limitation of trenchbroom. (when i try to expand the map size further, the brush just scales its self down.)

either way, im happy i chose to start with a test map to check limitations.

[ceriux]

Hey I was looking everywhere and can't seem to find anything is there any documentation on how to use all of hmap2's features such as the colored lighting?

[Madfox]

Quick google pointed to this.
It's a readme of Lord Havoc and Vic.

[mh]

[ceriux]

[toneddu2000]

[toneddu2000]

No, my fault. Apparently R_PolygonVertex() color bug is related to using glsl shaders to bsp brushes. Using common textures (like textures/common/caulk, etc.) solved the problem. It remains the bigger maps problem but, to be honest, I'm quite fed up to toying with FTE and BSP. Probably Crafter will use pre-compiled hull bsp boxes of different size and that's it

[toneddu2000]