Sign in to follow this  
eviltwigflipper

Doom 3 .map question

Recommended Posts

Can anyone clarify the Doom 3 map format for me? It seems as there are more then 3 coords per vertex(as seen below). ( 0 0 -1 123 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "textures/common/monster_clip" 0 0 0 How would you go about rendering this?

Share this post


Link to post
Share on other sites
maybe it's not a vertex, maybe it's an alpha value of some sort, maybe it's something else entirely. pretty much until someone figures out the map format i wouldn't bother trying to load DOOM3 maps. i'd be incrediably surprised if they didn't significantly change the file format.

-me

Share this post


Link to post
Share on other sites
its not alpha value(numbers range from positive to negative)....some people have allready figured it out(GTKradiant loads Doom 3 maps).

Mabye it has something to do with bumpmapping or gloss? It actually doesn't look that much different from Quake 3, besides the first vertex has more then 3 points

Share this post


Link to post
Share on other sites
Mabye someone can help me expand on this...but i think i figured it out:

This is a basic rectangle:

brushDef3
{
( 0 0 -1 0 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
( 0 0 1 -64 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
( 0 -1 0 64 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
( 1 0 0 -128 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
( 0 1 0 -128 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
( -1 0 0 0 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0
}


( 0 0 -1 0 ) ( ( 0.03125 0 0 ) ( 0 0.0078125 0 ) ) "textures/alphalabs/a_enwall20d" 0 0 0


The first section is the vertex's, in this case it is a square(but for patches/curvers, it can be any amount of vertexs). The second two sets of numbers are the texture coords for the bump-map, and for the real map. The next section is the texture name(odviouslly), and the last three numbers are ALWAYS 0, might be there for internal compatabilty...

Share this post


Link to post
Share on other sites
havent tryed doom3 yet (somehow i doubt my celeron433/128mb with gf2mx wont quite do it justice :) )
but anyways that looks very similar to quake3's *.map files.

Share this post


Link to post
Share on other sites
Quote:
Original post by zedzeek
havent tryed doom3 yet (somehow i doubt my celeron433/128mb with gf2mx wont quite do it justice :) )
but anyways that looks very similar to quake3's *.map files.


Does it have a 'Turbo' button?? Try pressing it [smile]

Share this post


Link to post
Share on other sites
well the first 4 floats look more like a plane to me

take a look in some more .map files and you'll see that the 3 first floats doas always form a unit vector

maybe the other two 3xfloats aren't the texcoords but information of the point in the plane?

but why does a brushDef3 has 6 vertices?

Share this post


Link to post
Share on other sites
Quote:
Original post by crozzbreed23
( 0 0 -1 123 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "textures/common/monster_clip" 0 0 0


looks like the first four numbers are a plane
the first 3 numbers are the normal, and the fourth is the distance to the plane from the origin (0,0,0)
you can calculate the vertices by intersecting all the planes

edit: damn, too late ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by crozzbreed23
The second two sets of numbers are the texture coords for the bump-map, and for the real map.


I think they are the x and y scales, offsets and rotation values as they are the same on every vertex. Also wouldn't it be easier to have the same texcoords for the diffuse map as for the bumpmap, or maybe convert texcoords if they differ in size?

Share this post


Link to post
Share on other sites
Quote:
Original post by Tree Penguin
Quote:
Original post by crozzbreed23
The second two sets of numbers are the texture coords for the bump-map, and for the real map.


I think they are the x and y scales, offsets and rotation values as they are the same on every vertex. Also wouldn't it be easier to have the same texcoords for the diffuse map as for the bumpmap, or maybe convert texcoords if they differ in size?


it's probably a 2x3 matrix..

Share this post


Link to post
Share on other sites
ok, next step :)

It seems that rendering a doom3 map is a little more complicated as a rendering Q3 map...

With the editor I can verify that the brushes are a set of planes. And I agree with LogicalError that the next thing is a 2x3 matrix. I think it is for translating the worldspace coordinates in texture coordinates.

The planes in the brush define a volume, so our vertices are the intersections of three planes.

Bye,
Oesi

Edit: typo

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The .map file holds the brush and patch descriptions and the entities. This file is compiled during the dmap process into a .proc and a .cm file. The .proc file contains informations to render the map and the .cm file contains information for collision detection.
Brushes are described by a plane (the first 4 numbers) and two points. This representation of a brush saves a lot of disk space for big maps.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The brush consists of 6 planes which are described by each line in the brushDef. Just to to clarify my last post... :)

Share this post


Link to post
Share on other sites
hmm...I'm quite shure that it's a 2x3 Matrix and not just "2 points".

I made a simple cube with a texture on it and for every plane it was the same matrix. So if it were points they wouldn't even lay in the plane...

Bye,
Oesi

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Right, they are the S and T texture vectors. I've read that with the two points on some other forum or so and didn't take a deeper look into it. It's obvious, because where else should the texture alignment be saved, doh!

Share this post


Link to post
Share on other sites
>>It seems that rendering a doom3 map is a little more complicated as a rendering Q3 map...

With the editor I can verify that the brushes are a set of planes. And I agree with LogicalError that the next thing is a 2x3 matrix. I think it is for translating the worldspace coordinates i<<

does doom3 come with a world editor with it?
+ is it any good?

Share this post


Link to post
Share on other sites
Quote:
Original post by Rickmeister
Quote:
Original post by zedzeek
havent tryed doom3 yet (somehow i doubt my celeron433/128mb with gf2mx wont quite do it justice :) )
but anyways that looks very similar to quake3's *.map files.


Does it have a 'Turbo' button?? Try pressing it [smile]


Totally offtopic but...


HAHAHAHAHAHAHAHAHAHAHAHAHAHA ... that made me squirt Dr. Pepper from my nose.

Share this post


Link to post
Share on other sites
well there is a map editor in doom3, but I can't say if it's useful or not, because I don't have any mapping experience, skills or knowledge ;)
But I guess ID created the game with it, so it should be quite good :)

Simply start D3 with "Doom3 +editor" or start the Game, press CTRL-ALT-~ to open the console and type editor <enter>. In both cases Doom3 will be started and then it switches back to the desktop with the editor.

Bye,
Oesi

Share this post


Link to post
Share on other sites
hmm...as the anonymous poster said the map file isn't the file to look at but the proc file is.

I haven't found a file spec yet and I don't understand it completly on my own.

Obviously Doom3 uses portals (should be convex) created by a solid leaf-based bsp-tree.

The proc file contains a lot of models. Some of the models are the leafs (called areas) of the bsp-tree, but I'm not sure about the others.

A model consists of some surfaces, similar to the faces in Q3 I think.

There are also some other structures like the connection between the areas (called interAreaPortals) and shadowvolumes (?).

To render the map we also need the map file, because the proc doesn't contain any information about entities.
The cm file is just the collision model so not directly of interest. I heard somewhere that the aas files are for collision detection of different monster sizes, it seems correct if you look into the files.

I'm not sure how visibility is handled in Doom3. Maybe they use only frustum culling (BBs of the areas or maybe testing the visibility of the interAreaPortals). But the proc Files doesn't contain any BBs.

Bye,
Oesi

PS: sorry for my english ;)

Share this post


Link to post
Share on other sites
the .proc files contains the 'level' data (sectors and portals) and some pregenerated shadow volumes. The .cm file is used for collision detection.
The level is rendered using a portal-based visibility algorithm.
I wrote some demo's reading the .proc and .cm files, which you can download here: http://developer.infi.nl/index.php?ID=5 (source code included)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this