Quake3World.com • View topic - Large maps & terrain questions

Quake3World.com Forums

Level Editing & Modeling

Large maps & terrain questions

Print view

Previous topic | Next topic

Topic Starter

Topic: Large maps & terrain questions

KillPixel
Trainee

Joined: 22 Jun 2014
Posts: 49

Posted: 12-13-2015 03:14 PM

Does anyone know where I can find examples of maps that are 16384*16384 and up?

Also, I'm looking for documentation on how to properly do terrain. Currently, I use just standard structural brushes. Aside from longer compile times, I've run into MAX_MAP_VISIBILITY when compiling. I'm not looking for info on terrain blending or lighting, just what the actual geometry should be made up of (bsp, ase, detail brushes+caulk, etc.)

Any input would be greatly appreciated!

_________________
KillPixel@YouTube

Top

VolumetricSteve
Insane Quaker

Joined: 05 Nov 2010
Posts: 449

Posted: 12-13-2015 05:27 PM

I bet some tutorials for Return to Castle Wolfenstein would help you out, but I've never mapped for that, so I'm only able to guess.

As for going above 16K*16K, i'm thinking that's an engine limitation....Obsidian would know for sure.

Top

Martinus
Veteran

Joined: 17 Jun 2013
Posts: 158

Posted: 12-14-2015 08:51 AM

Terrain brushes must be detail brushes. Don't make them too complex because that causes very bad r_speeds.
Increase the _blocksize if its necessary for less compiling time and bsp size, but I do not recommend you to do this (as I said just if really necessary).

_________________
My Quake 3 maps

Top

KillPixel
Trainee

Joined: 22 Jun 2014
Posts: 49

Posted: 12-14-2015 03:56 PM

ok, thanks.

I did a test using detail brushes and caulk with good results. Really just wanted to make sure that using detail brushes is an acceptable way of going about it.

I'm leery of using .ase because it may be overkill for my needs and the drawback of not being able to change its geomrety on the fly in radiant is a big deal to me. This would be lessed by having a good workflow, but I don't have that yet.

_________________
KillPixel@YouTube

Top

obsidian
I'm the dude!

Joined: 04 Feb 2002
Posts: 12498

Posted: 12-14-2015 04:43 PM

KillPixel wrote:
Currently, I use just standard structural brushes.

You've hit MAX_MAP_VISIBILITY because there are so many brushes that -vis is trying to take into account for visibility calculations that it has exceeded its limit. Converting them to detail basically says, "ignore these brushes for visibility calculations". Terrain does terrible things to -vis.

Creating terrain has "evolved" quite a bit since id Software started making terrain maps for Team Arena. RTCW required quite a bit of terrain in their maps, Wolf:ET further added a bunch of stuff. Various features were added into the the compiler over the years to facilitate all of that, making the Team Arena heightmap generated metashader terrain method super obsolete.

Read the first 5 tutorials here:
http://www.simonoc.com/pages/articles.htm

_________________
GtkRadiant | Q3Map2 | Shader Manual

Top

KillPixel
Trainee

Joined: 22 Jun 2014
Posts: 49

Posted: 12-14-2015 07:27 PM

informative tuts, thanks.

_________________
KillPixel@YouTube

Top

Quake3World.com | Forum Index | Level Editing & Modeling

I bet some tutorials for Return to Castle Wolfenstein would help you out, but I've never mapped for that, so I'm only able to guess.As for going above 16K*16K, i'm thinking that's an engine limitation....Obsidian would know for sure.

Terrain brushes must be detail brushes. Don't make them too complex because that causes very bad r_speeds.Increase the _blocksize if its necessary for less compiling time and bsp size, but I do not recommend you to do this (as I said just if really necessary).

informative tuts, thanks.

I bet some tutorials for Return to Castle Wolfenstein would help you out, but I've never mapped for that, so I'm only able to guess.

As for going above 16K*16K, i'm thinking that's an engine limitation....Obsidian would know for sure.

Terrain brushes must be detail brushes. Don't make them too complex because that causes very bad r_speeds.
Increase the _blocksize if its necessary for less compiling time and bsp size, but I do not recommend you to do this (as I said just if really necessary).