Forum

large maps help

Discuss the construction of maps and the tools to create maps for 3D games.

Moderator: InsideQC Admins

large maps help

Postby ceriux » Fri Feb 24, 2017 7:30 pm

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.

Image

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.
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby frag.machine » Fri Feb 24, 2017 8:52 pm

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)
User avatar
frag.machine
 
Posts: 1999
Joined: Sat Nov 25, 2006 1:49 pm

Re: large maps help

Postby Spike » Fri Feb 24, 2017 9:32 pm

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.
Spike
 
Posts: 2817
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: large maps help

Postby ceriux » Fri Feb 24, 2017 10:15 pm

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

Image

i also tried a few of those commands which didnt seem to do anything. perhaps i should give up on a massive map..
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby Spike » Fri Feb 24, 2017 11:24 pm

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
Spike
 
Posts: 2817
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: large maps help

Postby ceriux » Sat Feb 25, 2017 12:43 am

Thanks I'll check it out.
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby ericw » Sat Feb 25, 2017 3:06 am

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.
ericw
 
Posts: 83
Joined: Sat Jan 18, 2014 2:11 am

Re: large maps help

Postby ceriux » Sat Feb 25, 2017 10:08 pm

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.
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby ceriux » Fri Mar 31, 2017 5:53 am

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?
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby Madfox » Tue Jul 04, 2017 9:29 pm

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

https://github.com/mUogoro/QuakeHordes/blob/master/bin/hmap2/hmap2readme.txt

:cool:
User avatar
Madfox
 
Posts: 83
Joined: Sat Jan 15, 2005 3:13 pm
Location: Holland

Re: large maps help

Postby mh » Wed Jul 05, 2017 10:28 am

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.

This is a bug in QuakeSpasm's BoundPoly (QuakeSpasm ADMod fixes it):
Code: Select all
mins[0] = mins[1] = mins[2] = 9999;
maxs[0] = maxs[1] = maxs[2] = -9999;
There are a few other instances scattered throughout the Quake code (and presumably tools as well) where mins and maxs for a calculated bbox are initialized to 9999/-9999 or similar.
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
User avatar
mh
 
Posts: 2279
Joined: Sat Jan 12, 2008 1:38 am

Re: large maps help

Postby ceriux » Fri Jul 07, 2017 2:24 am

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

https://github.com/mUogoro/QuakeHordes/blob/master/bin/hmap2/hmap2readme.txt

:cool:



ah so only lit support.. oh well..
User avatar
ceriux
 
Posts: 2203
Joined: Sat Sep 06, 2008 3:30 pm
Location: Florida, USA

Re: large maps help

Postby toneddu2000 » Sun Jul 09, 2017 6:57 am

Trying to compile a quite big map (60000x60000x10000+)but compiler says

Code: Select all
************ ERROR ************
parsing brush on line 7, unknown token "brushDef"


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! :shock:
toneddu2000
 
Posts: 1146
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: large maps help

Postby toneddu2000 » Sun Jul 09, 2017 8:15 am

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
 
Posts: 1146
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: large maps help

Postby toneddu2000 » Sun Jul 09, 2017 11:46 am

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
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
}

They simply not work. FTE has tons of issues with transparent shaders and GLSL

If you want to create empty maps as "placeholder":
  1. 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 :confused: ).
  2. 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.
  3. Now you can add a "hull bsp room" that encompasses the void. In CraFTEr I'll explain how to do that

If you're creating a realtime editor to edit your map entities dynamically (as it should be in 2017), it's very important that you add the floor, otherwise, projecting mouse coords from 2d to 3d space will make the cursor coords not to be coherent (cursor could appear placed too far from mouse position for example), instead, having the floor that "intercepts" mouse traceline funcs will help you to have your cursor placed exactly where mouse is placed. No matter how you edit your traceline ray, even you block it at some specific distance, without floor, cursor won't be placed correctly
toneddu2000
 
Posts: 1146
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Next

Return to Mapping

Who is online

Users browsing this forum: No registered users and 1 guest