Help with 3q map format

Just too clear things up, I’m not just another noob trying to write a q3 type game, however, as I’m familiar with the q3 level tools (radiant), I’d like to use this tool to create basic geometry which I can then use in my programs, just so I can have pretty shapes on screen as I learn opengl

The problem is I can’t work out how to convert the vertex data from the 3q.map file into anything usable.

//Example .map file describes a cube with
//its centre at origin (well, it did in the
//editor);

{
( 64 8 -64 ) ( -64 8 -64 ) ( -64 0 -64 )
( -64 0 64 ) ( -64 8 64 ) ( 64 8 64 )
( -64 -64 64 ) ( 64 -64 64 ) ( 64 -64 -64 )
( 64 0 64 ) ( 64 8 64 ) ( 64 8 -64 )
( 64 64 64 ) ( -64 64 64 ) ( -64 64 -64 )
( -64 8 64 ) ( -64 0 64 ) ( -64 0 -64 )
}

So, I coped the data by hand into a 2d array[6][3] and tried lots of silly looping methods to get it to draw a cube, but nothing happened, the closest I got was a couple of triangles in very odd places ;D

So, assuming I’ve got this data in array[6][3], what do I need to do to get it to display a cube. Or I’m I totally barking up the wrong tree here and do I need to approach this in a different way?

Btw, This format doesn’t make much sense to me to be honest, I ‘think’ that one line of the above text represents a triangle, and that two triangles will make one side of a cube, but then I only have a 3 sided object, clearly I’m missing something important

Thanks all.

The .map format just stores general information about the brushes and entity you edited with q3radiant. To get usable data to render from you have to “compile” this into your own or quake3’s bsp format with the q3map.exe tool which creates the bsp tree, surfaces, etc.
You should have a look at the q3radiant source code. There you’ll find the complete source for the q3map tool.

Hope this helps

Originally posted by Jens Scheddin:
[b]The .map format just stores general information about the brushes and entity you edited with q3radiant. To get usable data to render from you have to “compile” this into your own or quake3’s bsp format with the q3map.exe tool which creates the bsp tree, surfaces, etc.
You should have a look at the q3radiant source code. There you’ll find the complete source for the q3map tool.

Hope this helps[/b]

I that’s probably a little advanced for me, but I’ll look into it, cheers.

What does the info in the above snippet mean though, if I could understand how it was used to define a cube that would be a big help.

Thanks.

http://graphics.stanford.edu/~kekoa/q3/ <- Describes the map format of quake 3 .bsp files. These files are generated by compiling the .map file with the q3map.exe (in the radiant editor through the menu “bsp/…”) and are actually the files you need for rendering.

http://www.cs.brown.edu/research/graphics/games/quake/quake3.html <- Describes how to render a quake3 level (.bsp file).

You can also try a search on google with something like “quake 3 render map” or so. There’s plenty of stuff on the net about it. Or search for the Tenebrae or Titan engines which are open source and do render quake 3 maps (the tenebrae engine might be too advanced to begin with, maybe). But before looking at these you should understand the basics about quake 3 .bsp files.

Ok, cheers Jens, and thanks for the links.

Btw, if anyone does know how to convert the above brush information into a usable vertex array, that would be cool

[This message has been edited by kellog (edited 03-13-2004).]

Funnily enough, I’ve been working on a BSP compiler this week and have been using Q3 .map files as test data, so I’ve been dealing with these beasties a lot the past couple of days

Each line describes a single plane that bounds the brush’s solid space (3 points is enough to describe a plane). What you need to do to get vertices is:

  1. Calculate the plane coefficients for each surface of the brush. (hint: the plane normal is Normalize( CrossProduct( (p[1]-p[0]), (p[2]-p[0]) ) ) )

  2. Create a polygon that lies on that plane. This can be tricky, but essentially you need to find the axis of the plane normal with the largest magnitude and make up a tangent and binormal for the surface. Once you have those you can use the plane’s origin and the tangent and binormal (scaled way up) to create a large quadrilateral.

  3. Clip the polygon down by all the other planes in the brush, throwing away anything in front of a plane, keeping anything behind the plane.

repeat for all surfaces in the brush.

At the end you might want to weld vertices, just in case some floating point error crept in.

If you just want some easy to deal with test models then you’re probably better off using a modelling package like Milkshape and writing an exporter (or seeing if there’s an exporter for a format you already know). If you want proper brush information then Radiant (and it’s ilk) is the way to go.

Crikey, cheers SmutMonkey, clearly, these not the droids I’am looking for

I had no idea it was that complicated, I just guessed the map file would be simple shape descriptions. I think I’ll look for something that outputs .obj files

Anyway, cheers for a nice description on how the brush format works though, I’m definitely going to look into it, reckon it will be a bit of a headache, but hay ho

Cheers guys

I’ve just been looking at some wire renders of the above brush description and now it all makes sense (thanks to SmutMonkey’s explanation), the thing is though, why did id choose this format in the first place, was it purely to keep the map file size down or are there other benefits?

Not that it matters much, it’s just that if you look at something for long enough it becomes intriguing

It seems like a weird way to describe a shape to me but I’m new so what do I know.

Brushes are also known as convex hulls, and convex hulls have some nice properties.

The best thing about them is, if you can prove a point in space is in front of any of the planes, then the point is guaranteed to be outside the hull. Expand on that and you can see how ray intersections are also pretty trivial with a convex hull. (Box and sphere collisions require a bit of extra fiddling about because you have to add extra planes along the edges, commonly called bevel planes, otherwise you get false positives, but it’s easy enough to work around).

The whole thing with id using them is related to the fact that the BSP trees in Quake store polygons in the front leaves and anything in the back leaves of the tree is considered to be solid space (i.e. you can’t get in there because it’s filled in).

Once you get into the intricacies (and the nastiness ) of the whole BSP/Portal/PVS thing then it makes a lot of sense being able to mark regions of space as being filled in.

I think Unreal does a similar thing, but the editor requires you to carve out empty space from an initially filled space (IIRC). Same sort of principle and, again, related to the concept of having solid/non-solid leaves in the BSP tree.