Mapping for QW... what do we know by now?

(]UBC[ McNite) #1

Just wondering whether we already know some details on how the QW mapping will work?

The other thread states the sounds will be .ogg, but no details really.

I heard its a new format named .world, and that you can build parts of your maps as .world files and then implement them into the maps like models, rotating them with any degree you want?

Last thing i heard about the editor was that they are going to separate it from the games engine, so does the editor come with the game or separately like the radiant?

And what are the news about shaders, the scripting system?
Will we be able to define which vehicles and weapons can be used (talking about the “fire from the sky” weapons here) since it does make sense that you can exclude certain vehicles and weapons from a map for gameplay’s sake.

What is worrying me with the quality of the pics you can see is how large your custom textures need to be with regard to filesize of new maps…

(zeh) #2

Little is known, specially because the MT is something new. SD did talk a bit about it on QuakeCon 2006, including answering questions from the audience, and you can find that presentation in video.

High-res download:
http://www.planetquake4.net/download.php?op=fileid&lid=2334

Crappy YouTube version:




That’s probably everything that is publically known at this time.

Other than that, there are small, more technical tidbits of information that people have been gathering about MT, and some stuff people has developed with D3’s version of MT (which is an old version of the technology).

http://www.doom3world.org/phpbb2/viewtopic.php?t=10673
http://www.doom3world.org/phpbb2/viewtopic.php?t=17912
http://www.doom3world.org/phpbb2/viewtopic.php?t=18302

One of the things some devs have said in the past is that MT is just another feature. You don’t have to use it if you don’t want to. Yes, there will be a huge texture file if you want (around 500mbs per map on SD’s case). But it’s up to the level designer to decide if he wants that.

(carnage) #3

this actualy seems like a realy good idea for a thread of anyone is willing to actuly take change of it and orgonise all the surgestions into a a nice format so we can start looking at things that might be good to learn and prepere for the coming QW

my contribution (from what i can remeber in thoes videos)
-the mega texture beigns as a current texute by tiling textures accross it
-the texutres can be applied automaticaly based on steepness of the surface the texture is on
-the automated texture positions can be overriden if you wanted to put a cliff face texture on a level part of the terrain
-there is a tool to draw roads onto the megatexture simply be defining a path for them
-extra detail is added by process of a “decal stamp” tool where im gessing textures that are similar to the decal textures we use in ET mapping are drawn over the mega texture rather than rendered larter using a polly ofset shader technique
-this implies that you can use an unlimited number of decal texturtes without the wory of having to have them in memory when the map is running or supply them with the pk3. (AFAIK SD are going to release the entire library of decal textures with the game for meppers despited them not actuly being needed to view the textures)
-the decal stamp tool is used in game rather then in editor (not sure about this one)
-the mega texture is compiled seperatly to the map (again not sure) then compresed to about 1/3 the size it will be on the hard drive for data trasfer purposes
-there is not fixed resolution for mega textues so resolution can be lowerd to make for smaller pk3 files
-the mega texture holds data of traction of vehicle physics calcualtion. There is no information on how this is appled although it would seem likely that it would gather the information from the original tiling textures first used to make the basic mega texture and assosiated shader files (posibly making expetion for where the road tool is used to give the feeling or better traction when on a road)

questions this leaves
-what are the limits to the size of decal textures you are able to apply over the mega texture
-how exactly is traction information given to the mega texture
-how does the road tool work

related questions
-is a sperate lighting method used to light the terrain, asuming the game uses static times of day in the maps then lighting something as large as the terrain dynamicaly would seem quite a waste when the lighting will not chage on it
-how does the terrain cast shadows if it does so in the conventional sence. AFAIK doom3 engine traces points though each vertice onto a surface to create a stencil to mark the area light will not effect. the terrain is created from a very high number iof vertices is it posible to actuly process this volume of shadow data in this way

will try and post stuff on other related QW mapping toppics when they come to me

(organon) #4

The thing I’m most interested in is, how the edge of the map is handled. My last mapping experiences were in Q3A times, and there you always had a bounding box, which seemed reasonable given that it was mainly an indoor engine. Bur here wee have this nice megatexture thing. But you are certainly able to look further than the 32k^2 grid. So how is terrain made visible beyond that? Or are you always required to contain the map within mountains as a natural barrier? Since it would certianle be nice to have the option of a an islan map surrounded by sea, or in wide flat desert etc.

And I have a great idea for a map already. I can’t wait to do some mapping again after a few years :smiley:

(ayatollah) #5

I don’t know how you are going to avoid the whole “bounding box” idea. A map has to end somewhere but there are ways to incorporate the “look” of wide open spaces.

(organon) #6

And I’m not talking about anything else … what possiblities does the engine have to make it look like it goes on and on?

(ayatollah) #7

That could come down to artistic skills really! :wink:

(MuffinMan) #8

being really bad at drawing I would still prefer to use terrain texture tiles (and because of the download size for the player) - does anybody know if there will be terrain textures included or do we have to make a custom megatexture for every map?

(ayatollah) #9

You don’t have to use the MT, you can use seperate tiles if you wish. I would think that there will be some stock texture tiles available for use but MT tech is probably the way forward. May be large but requires less polygons for terrain…I think! :stuck_out_tongue:

(organon) #10

I don’t know wether you know the scoreched3d game (http://www.scorched3d.co.uk/). They have done a quite nice job of putting an island in the ocean. Of course the engine has other priorities and purpose, and certainly had less development time and experience than id engines. I wonder wether the qw engine could provide something like that. I know it wouldn’t be really be possible to do something like that in the vanilla Q3A engine. And sacrificing substantial amounts of the megatexture real estate to create the illusion of vastness is not a really satisfactory solution for that imho. After all, a square mile isn’t that big. Back in school I ran the 1000m in 3:15min. And this is a game where we have copters with jets.

(carnage) #11

The thing I’m most interested in is, how the edge of the map is handled. My last mapping experiences were in Q3A times, and there you always had a bounding box, which seemed reasonable given that it was mainly an indoor engine. Bur here wee have this nice megatexture thing. But you are certainly able to look further than the 32k^2 grid. So how is terrain made visible beyond that? Or are you always required to contain the map within mountains as a natural barrier? Since it would certianle be nice to have the option of a an islan map surrounded by sea, or in wide flat desert etc.

And I have a great idea for a map already. I can’t wait to do some mapping again after a few years Very Happy

the two most likely solutions are that the players will be restrickted inside a play area and the megatexture extends outside of that untill the atmospheric fog hides the edges. or that large hills will cover the sides of the map if there are any maps without aircraft

(Tron-) #12

I would expect the engine to support skyportals to create this effect. or there is always the possibility of doing it like in Battery where the water fades out at a distance.

(Danyboy) #13

its not just an issue of system hardware. it’s no use having vast maps if there’s nothing to do in it.

logical clipping to restrict player movement is essential in keeping players close enough to fight but further enough away to give a sense of freedom. Plus it also allows mappers to be clever in the way they clip the world. Invisible walls are lazy and frustrating, the sloping skybox in Battery was much nicer, plus fog to the far plane made it look realistic.

<bash>
BF2 got this quite wrong and if you ejected from a plane at the wrong moment its a 10 minute walk to civilisation
</bash>

I do remember playing Delta Force Land Warrior and some clan mates decided to walk to the edge of the map. These maps were many square kilometers and it took them about half and hour :smiley:

(organon) #14

While figuring out how to “physically” (as far as anything simulated can be physical) restrain player from leaving the game area is a really interesting one and porbably always depends on the scenario. Especially when you have flying units it can become really tricky if you don’t want to engage in invisible walls.

I’m more interested in the pure visual aspect of it though.
With the megatexture you have one square mile of real estate to work with. If you don’t want any player to ever see the edge of the map artifacts, you gotta devote quite a bit of the real estate to make the boundaries look natural, thus only more restricting the space. For pure ground combat that might be ok. But as soon as you have flying units it’s very hard not to feel trapped in a square mile.

Anyway … I guess we won’t know until we can have our hands on the SDK.

And damn, I have far too many ideas for maps already …

(SniperSteve) #15

Unless you want to go BF2 style where you start taking damage once outside an invisible barrier.

(carnage) #16

or starwars starfighter style where the game simply turns your player/ship around. not perfect but better then your plane hitting an invisible wall and crashing to the ground

(mortis) #17

One of the best things I liked about unrealed (for mapping in UT) was that you could compile as you go, and use the realtime 3D window to view the applied changes. If I had a program to convert unreal maps to radiant .map or bsp, I could make a different map every week. building the level geometry in UT is soooooooooo easy…plus the terrain generator is equally easy to use. UT didn’t use caulk, but you could place antiportal brushes in solid objects to increase FPS. So easy.

I guess there are some mappers who are that good with Radiant, but I find it much harder to deal with. I guess I better learn the Doom 3 editor if I want to do anything for ETQW…

(kamikazee) #18

The Doom 3 editor can be used, but it is a step back from the ease of use we got to know in GTKRadiant.

The QWeditor on the other hand is said to be extended and improved in many ways, so it might even be better as not to mess around with D3E unless you still know how Q3Radiant works.

(Hakuryu) #19

Here is some stuff I’ve copied to text documents.

Info from Wils on SD boards:

The terrain mesh is made in a modelling package. The megatexture is the bit that is created in the editor.

Our base mesh typically begins life as a 32768 x 32768 unit plane with 128 subdivisions. This is about equivalent to the mesh tesselation in Wolf, so is good for roughing out detail and getting playable terrain. We then add more detail where needed to shape cliffs and outcrops, and reduce tesselation locally in flatter areas.

From Birdawg

As of right now we support .ma, .obj, .lwo, .ase, and our own .surf format. If the engine can load it as a model, you can use it as a terrain model. Last I checked, we tended to use .lwo most frequently, followed by .obj.

BirdDawg wrote:
The ETQW map format (.world) is a new format that supports easily adding new primitive types, metadata such as grouping information, and arbitrary properties on everything. The base primitive data stored will be familiar:
faces have planes, a 2D texture matrix + offset, material, and texture bounds (a new little toy we’ve cooked up.) Patches have control points and UV data, as well as their own additional texturing info. The format also supports references to other .worlds (these can be nested inside of each other.)

Quote Wils

A world unit is 1 inch, or 2.54cm in RTCW and Wolf ET. Radiant units == Game units, so you can open up the goldrush.map that comes with the Wolf ET tools to get sizes for everything, and convert from there.

We use the same scale in ETQW, incidentally.

(Loffy) #20

The level editor used to make ET:QW (World Edit) is described by the SD team at QuakeCon2006: