I''m not sure if other utilities dump to this format, but I was playing with Worldcraft 3.3 and exported a simple level to the .MAP format. A sample section that makes up one polygon is: { ( -408 -144 39 ) ( 560 -144 39 ) ( 560 -144 -315 ) WALL1 [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( -408 -144 -315 ) ( 560 -144 -315 ) ( 560 -122 -315 ) WALL1 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( 560 -122 39 ) ( 560 -144 39 ) ( -408 -144 39 ) WALL1 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 ( 560 -144 -315 ) ( 560 -144 39 ) ( 560 -122 39 ) WALL1 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( -408 -122 39 ) ( -408 -144 39 ) ( -408 -144 -315 ) WALL1 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 560 -122 39 ) ( -408 -122 39 ) ( -408 -122 -315 ) WALL1 [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 } Documentation states that "The first three sets of numbers - ( 0 0 64 ) ( 128 0 64 ) ( 128 -128 64 ) - are X Y Z values." Of course the name following is the texture, but then I have no further info on what the following numbers represent. However a typical call to glVertex3f(x,y,z) are floating points. Has anyone run across this and have a solution they can offer as to how you would convert this format to one which is usable for drawing a world?

The numbers after the textuer name are the texture offsets. Search around on http://www.planetquake.com . They have a page dedicated to the map file format. Sorry i dont know the exact link.

Snyper

{
( -408 -144 39 ) ( 560 -144 39 ) ( 560 -144 -315 )
( -408 -144 -315 ) ( 560 -144 -315 ) ( 560 -122 -315 )
( 560 -122 39 ) ( 560 -144 39 ) ( -408 -144 39 )
( 560 -144 -315 ) ( 560 -144 39 ) ( 560 -122 39 )
( -408 -122 39 ) ( -408 -144 39 ) ( -408 -144 -315 )
( 560 -122 39 ) ( -408 -122 39 ) ( -408 -122 -315 )
}

just in case u might not know....
those numbers(what u listed, without the texture stuff) are describing 6 planes to make up your polygon.



-NetArc

A mate of mine grabbed the source for qeradiant somewhere (cant remember where), and he was able to make a proggy load and view/walk through .map files quite easily (though with no culling).

Maybe you could see how qeradiant does it (search for the source or sumthin)

Cel

Cel, any chance your friend would be willing to release the source to their utility?

I''m still attempting to dig up the specifics regarding the .MAP format though. I''m surf''n planetquake as referenced above, but I haven''t really found anything in regards to detailed info.. and the search features are somewhat limited on that site. =)

I''ll see if I can dig up source to qeradiant in the interrim. Any help would be appreciated. =)

Thanks for all who have replied thus far. =)

Hi Sleepy

Next time my mate comes online, I''ll ask him.

He prolly wont mind, he basically hacked around with the qeradiant source, stripping off all the crap not needed to view .maps.


I''ll get back to you if I talk to him soon

Cel

Well I found a web site that contains a slew of information, the link (for those who might be interested) is

http://www.gamers.org/dEngine/quake/

Cel:

I also downloaded the SDK kit for QERadiant.. yet to determine if it contains what I need for reading the .MAP format tho.

Apparently the .MAP format is what Quake 1 and 2 used.. and still used in Quake 3, but the contents and everything else (triggers, etc) are now compiled into a BSP file which actually contain the "floating point" vertices that I''m trying to determine how they are calculated. =)

I''m still game if your friend can supply whatever he might be willing to share. =) You or your friend can reach me by email at mriggs@acssys.com, when time permits.


NetArc:

That one set of 6 lines is actually definitions for 1 plane (although by looks of it, I would misconstrue each line as 3 planes), as there are 5 additional sets of 6 lines making up the total of 6 planes as you thought those lines represented.

It''s nothing complex either, just a small room with 3 textures and some lighting.

What I''m trying to figure out is how you determine the floating point based on each line. A typical call is glVertex3f(1.0f, 0.0f, 0.5f);

The first line of the MAP format:
( -408 -144 39 ) ( 560 -144 39 ) ( 560 -144 -315 )

..actually represents 1 point. So (-408 -144 39) would (somehow) equate to 1.0f, (560 -144 39) would be 0.0f, and (560 -144 -315) would be the 0.5f of the above "typical" example. Keep in mind, these are not true representations of the actual conversions.. that is what I''m trying to figure out. =)

I''m hoping with the QERadiant SDK I can determine how they do this conversion and then I''ll be one happy camper!

As for the coordinates being specified as int''s, just use
glVertex3i rather than glVertex3f.

-Neophyte

- Death awaits you all with nasty, big, pointy teeth. -

Each part between { } in the "worldspawn" class describes something the Quake people wanted to call a brush. A brush is just a convex volume of 3D space. One line in a brush describes a single plane of infinite extent by prescribing three points on this plane (in clockwise order). The following numbers and filenames indeed describe texture information. (I''m not quite sure what the last three numbers on a line do in the Quake 3 .map file format. I''d really like to know!) The volume is the volume bounded by the planes. (Think of a cube as a volume of space bounded by six planes of infinite extent.) (Is this clear?)

I also figured out what the syntax for the curved surface patches is. If anyone wants to know, drop a line.

Maybe I''m trying to analyze this too much, and please excuse my newbiesness.. I''m still reading a lot and trying to digest it and relate it to examples I''ve already had working. With what I know and what I read sometimes it''s hard to make the comparison or grasp the right methology until I have the right analogy. =)

I understand the concept behind what is defined as a "brush" (tied in with coordinate systems), but taking that into consideration I analyze a single (Quad) brush as such:

(x1y1z1) (x2y2z2)
(1)---------(2)
! !
(3)---------(4)
(x3y3z3) (x4y4z4)

In talking to ValveSoftware I received a response to their 3.3 MAP Output format and the base of the line syntax is like:

(x1 y1 z1) (x2 y2 z2) (x3 y3 z3) [Texture] ....

But considering the current output having 6 lines per brush, I would be led to believe one actual brush is represented by 2 [GL_TRIANGLES], as each triangle is represented by 3 points, each point having an X,Y,Z.

What I''m kinda confused on in a sense is I look at the one brush and see 4 points, representing a QUAD. Each point consisting of an X,Y,Z. So a common Quad would be derived from:

glBegin(GL_QUADS);
glVertex3f(-1.0f, 1.0f, 0.0f); // Top Left
glVertex3f( 1.0f, 1.0f, 0.0f); // Top Right
glVertex3f( 1.0f,-1.0f, 0.0f); // Bottom Right
glVertex3f(-1.0f,-1.0f, 0.0f); // Bottom Left
glEnd();

Is it faster to draw 2 [GL_TRIANGLES] to represent one solid brush, or is it ideal to draw one GL_QUAD for this?

When I return home later I''ll post the current format I got from ValveSoftware, regarding what each position following the texture represents.

Everything I''ve been reading refers to using "floating points", however due to the .MAP format using integer values someone mentioned using "glVertex3i(x,yz)".

My question to this then is what do you use for the "glTranslatef(x,y,z)" values since they are indictative of using floating points verus integers

I have a few books on the way.. which should help some. In the interrum if anyone in their infinite wisdom can assist on this I''d appreciate it!