large maps help
large maps help
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.
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.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: large maps help
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: large maps help
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.
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.
Re: large maps help
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..
i also tried a few of those commands which didnt seem to do anything. perhaps i should give up on a massive map..
Re: large maps help
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: http://forums.insideqc.com/viewtopic.php?f=1&t=172
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: http://forums.insideqc.com/viewtopic.php?f=1&t=172
Re: large maps help
Thanks I'll check it out.
Re: large maps help
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.
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.
Re: large maps help
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.
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.
Re: large maps help
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?
Re: large maps help
Quick google pointed to this.
It's a readme of Lord Havoc and Vic.
https://github.com/mUogoro/QuakeHordes/ ... readme.txt
It's a readme of Lord Havoc and Vic.
https://github.com/mUogoro/QuakeHordes/ ... readme.txt
Re: large maps help
This is a bug in QuakeSpasm's BoundPoly (QuakeSpasm ADMod fixes it):Spike wrote: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.
Code: Select all
mins[0] = mins[1] = mins[2] = 9999;
maxs[0] = maxs[1] = maxs[2] = -9999;
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
We knew the words, we knew the score, we knew what we were fighting for
Re: large maps help
Madfox wrote:Quick google pointed to this.
It's a readme of Lord Havoc and Vic.
https://github.com/mUogoro/QuakeHordes/ ... readme.txt
ah so only lit support.. oh well..
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: large maps help
Trying to compile a quite big map (60000x60000x10000+)but compiler says
Does hmap2 support Quake3 maps? Is it possible that in 2017 it is so difficult to create huge maps?!
Question to Spike: I created an empty (and leaked) bsp (just info_player_start, a brush and a light), in FTE I create bsp at runtime to create a bsp room and it works, but elements drawn at runtime via R_PolygonVertex() lose their color (all black), instead, if I use a small map created with NetRadiant, colors appear as they are!
Code: Select all
************ ERROR ************
parsing brush on line 7, unknown token "brushDef"
Question to Spike: I created an empty (and leaked) bsp (just info_player_start, a brush and a light), in FTE I create bsp at runtime to create a bsp room and it works, but elements drawn at runtime via R_PolygonVertex() lose their color (all black), instead, if I use a small map created with NetRadiant, colors appear as they are!
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: large maps help
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
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: large maps help
Again, my fault. R_PolygonVertex() is not responsable for not showing colors of shaders.
In case, someone is interested(probably no one, but whatever)..
If you create in fte BSP brushes at runtime, you cannot use transparent shaders, so, if you plan to creat big (or small) runtime bsp maps in fte, avoid these kind of shaders
They simply not work. FTE has tons of issues with transparent shaders and GLSL
If you want to create empty maps as "placeholder":
In case, someone is interested(probably no one, but whatever)..
If you create in fte BSP brushes at runtime, you cannot use transparent shaders, so, if you plan to creat big (or small) runtime bsp maps in fte, avoid these kind of shaders
Code: Select all
axisx
{
{
program ton_flatcolor#RED
blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
alphaFunc GT0
depthWrite
rgbGen identity
}
{
rgbGen identity
blendFunc GL_DST_COLOR GL_ZERO
depthFunc equal
}
cull none
}
If you want to create empty maps as "placeholder":
- just put a floor in your quake3 map editor sw big enough to cover let's say 16000x16000x64 units, put an info_player_start and a light with targetname key and radius of 1 (it won't be used in game, but fte doesn't work correctly with dynamic light if map doesn't have a named light ).
- Make sure your compiler won't stop if map is leaked (in NetRadiant there's preferences manu to do that) and you're done. Your empty map is ready.
- Now you can add a "hull bsp room" that encompasses the void. In CraFTEr I'll explain how to do that
Meadow Fun!! - my first commercial game, made with FTEQW game engine