Size limitations

[Ebisu]

Hello there fellow Quake mappers. I have a question for anyone who can spare me a solution. What is the absolute largest size you can make a Quake map in all dimensions, and what source port/bsp compiler would be required to render it properly?

[Dutch]

Howdy. I'm no expert but I do know this depends on two things: the quake engine itself and the compiler.

Compiling HMAP2 and using darkplaces or fte is probably the way to go if you are aiming for a huge map. I'm sure someone will chime in with more info.

[PrimalLove]

4096 units is the base maximum unit size of a BSP of most quake engines. Darkplaces is capable of 1073741824 units. In real terms its probably equal to a bit over 1/3 of the earths surface area if you were to create a map that size. Several example maps like this have been created tho I am not sure of any that has reached the full unit capacity. I am not sure about FTE but maybe Spike will chime in on his engine. I have no idea if a map of this size would actually run but theoretically its possible. I believe DirectQ also has much greater limits for BSP. As far as what map editor to use not sure about that but for compilers you can use Bengt Jardrup's tools or hmap2. I'd probably stick with hmap2 if you are going to use DP. Hmap2 can be found at the DP site here. I personally use TrenchBoom because its intuitive and easy to learn but perhaps not as powerful as radiant based map editors like GTKradiant BSP2 is produced by hmap2 and theoretically you could create a map of any size and complexity tho whether it will run well in the engine is a different matter.

Good luck!

[golden_boy]

The reasonable thing to do is often to chop large environments into smaller levels, for reasons of performance and to save compile time.

[Spike]

here's some size limits:
+/-4096qu - networking coord limit (fixed by protocol extensions, may require cvar tweaks due to the compatibility issues this raises)
+/-32767qu - bsp node/leaf bounds limit (fixed by bsp2, or recalculated)
there are numerous engines now that have a way around those two size limits.

complexity limits are more awkward to describe. the bsp2 file format raises the limit of pretty much everything inside the bsp to about 4 billion entries. which is an insanely high number that noone is likely to reach. that said, due to the way pvs works, there may still be engine-imposed limits on the number of leafs even in the best engines.
despite this, you should be able to achieve maps that are too large to be practical.
Any further complexity limits would be better described as detail limits...
Regarding detail, you'll probably find that q3bsp's misc_model stuff results in easier and nicer results that are simply not feasably possible with quake1 tools.

While I'm not aware of anyone trying it, bsp2 should be sufficient to build all four episodes into a single map.
Which would be awesome, if you liked iron-man type games (where one death means starting from scratch)...

Urre made a map years ago now involving a mega tower standing above the earth (1/3rd of the earth's radius high). It had a skybox which was really just a REALLY HUGE box in the map itself.
After spending the 10/15 minutes in free-fall with terminal velocitities massively increased, you notice that while the engine appears to be able to mostly cope, the graphics card starts glitching with some really ugly floating point precision issues. Thankfully there's no real detail there either, which is probably how the engine doesn't massively glitch out with physics.
Long story short, theoretical limits are generally not practical limits. And insane maps are awesome, but suck for detail.

[Ebisu]

Thanks for the information guys. Just curious about limitations for some of the things I am experimenting with. My inquiry arose when my friend said FTE was crapping out when trying to render something he whipped up in TrenchBroom, so I made a large plane with a skybox and as it turns out FTE stops rendering after a certain distance. I didn't experience this in Darkplaces. Is FTE cutting off because of bsp size limitations, or something else? I remember my compiler complaining when I made a plane that was absurdly larger than the one I made to test in FTE, so maybe that was the limitations of a bsp and FTE's problems was something different?

And out of unrelated curiosity, since you're here Spike, Quake 2 seems to be broken in some of the newer releases of your engine. Are there any plans on fixing that? I tried to contact you via IRC but you were away.

[Spike]

in fte, just set gl_maxdist to 0, and it'll switch to some infinite distance logic (at the expense of more z-fighting, which is why its not default). I forgot about that one, sorry.

regarding q2, seems to work for me, you'll need to be more specific before I'll know what to fix. :s
with IRC, try pms or actually saying the person's name, because there's a lot of people who are just idling... I missed you by about 5 mins last time (I assume that peson was you).

[Ebisu]

Here's a screenshot of what happens when I try to start Quake 2 singleplayer. It works just fine with an older version of the fteqw executable.

Also thanks for the information regarding rendering distance.

[Spike]

64bit builds cannot run 32bit gamecode - the gamecode must be recompiled for that.
This is a cpu archetecture limitation, rather than an FTE-specific one, 32bit dlls are simply not usable in a 64bit process.
Just run a 32bit build for your server, then it can use the vanilla 32bit game dll (or mods), just like any other q2 engine would. Saves recompiling/debugging the mod.

Although I admit it should print something more meaningful...