Quake .map format versus .Map 220 format

Discuss the construction of maps and the tools to create maps for 3D games.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Quake .map format versus .Map 220 format

Post by Baker »

[This info might eventually lead to being able to automatically convert brushes from one to the other]

Quake: (x1 y1 z1) (x2 y2 z2) (x3 y3 z3) texture x-shift y-shift angle x-scale y-scale

Map 220 (Valve) : (x1 y1 z1) (x2 y2 z2) (x3 y3 z3) texture [x-texvector x-shift] [y-texvector y-shift] angle x-scale y-scale

http://www.gamers.org/dEngine/quake/spe ... index0.htm

See Ben Jardup's txqbsp source:

Code: Select all

map.c ParseBrush in txqbsp ...

void ParseBrush (void)
{

		Valve220 = false;

		tx.miptex = FindMiptex (token);
		GetToken (false);
		
		if (!strcmp (token, "["))
		{
			// Valve 220 map import
			Valve220 = true;
			GetValveTex (VAxis[0]);
		}

		shift[0] = atoi(token);
		GetToken (false);
		
		if (Valve220)
		{
			// Skip ]
			GetToken (false);
			GetValveTex (VAxis[1]);
		}

		shift[1] = atoi(token);
		GetToken (false);

		if (Valve220)
			GetToken (false); // Skip ]

		rotate = atoi(token);
		GetToken (false);
		scale[0] = atof(token);
		GetToken (false);
		scale[1] = atof(token);

Code: Select all

static void GetValveTex (vec3_t VAxis)
{
	int i;

	// Skip [
	GetToken (false);
	
	for (i = 0; i < 3; i++)
	{
		VAxis[i] = atof(token);
		GetToken (false);
	}
}
And this is where conversion happens ....

Code: Select all

		if (txcommand=='1' || txcommand=='2')
		{		// from QuArK, the texture vectors are given directly from the three points
			vec3_t	TexPt[2];
			int		k;
			vec_t	dot22, dot23, dot33, mdet, aa, bb, dd;

			k = txcommand-'0';
			for (j=0; j<3; j++)
				TexPt[1][j] = (planepts[k][j] - planepts[0][j]) * ScaleCorrection;
			k = 3-k;
			for (j=0; j<3; j++)
				TexPt[0][j] = (planepts[k][j] - planepts[0][j]) * ScaleCorrection;

			dot22 = DotProduct (TexPt[0], TexPt[0]);
			dot23 = DotProduct (TexPt[0], TexPt[1]);
			dot33 = DotProduct (TexPt[1], TexPt[1]);
			mdet = dot22*dot33-dot23*dot23;
			if (mdet<1E-6 && mdet>-1E-6)
			{
				aa = bb = dd = 0;
				Message (MSGWARN, "Degenerate QuArK-style brush texture on line %d", scriptline - 1);
			}
			else
			{
				mdet = 1.0/mdet;
      			aa = dot33*mdet;
      			bb = -dot23*mdet;
				//cc = -dot23*mdet;     // cc = bb
				dd = dot22*mdet;
			}

			for (j=0; j<3; j++)
			{
				tx.vecs[0][j] = aa * TexPt[0][j] + bb * TexPt[1][j];
				tx.vecs[1][j] = -(/*cc*/ bb * TexPt[0][j] + dd * TexPt[1][j]);
			}

			tx.vecs[0][3] = -DotProduct(tx.vecs[0], planepts[0]);
			tx.vecs[1][3] = -DotProduct(tx.vecs[1], planepts[0]);
		}
		else if (Valve220)
		{
			// Valve 220 texturedef
			vec3_t vec;
			vec_t  tscale;

			// Prevent division by zero
			if (!scale[0])
				scale[0] = 1;
			if (!scale[1])
				scale[1] = 1;

			// FIXME: If origin brushes are in use, this is where to fix their tex alignment!!!
			for (i = 0; i < 2; ++i)
			{
				tscale = 1 / scale[i];
				VectorScale(VAxis[i], tscale, vec);
				
				for (j = 0; j < 3; ++j)
					tx.vecs[i][j] = (float)vec[j];
				
				tx.vecs[i][3] = (float)shift[i] + DotProduct(vec3_origin, vec);
			}
		}
		else
	//
	// fake proper texture vectors from QuakeEd style
	//
		{
			vec3_t	vecs[2];
			int		sv, tv;
			vec_t	ang, sinv, cosv;
			vec_t	ns, nt;

			TextureAxisFromPlane(&f->plane, vecs[0], vecs[1]);

			if (!scale[0])
				scale[0] = 1;
			if (!scale[1])
				scale[1] = 1;

		// rotate axis
			if (rotate == 0)
				{ sinv = 0 ; cosv = 1; }
			else if (rotate == 90)
				{ sinv = 1 ; cosv = 0; }
			else if (rotate == 180)
				{ sinv = 0 ; cosv = -1; }
			else if (rotate == 270)
				{ sinv = -1 ; cosv = 0; }
			else
			{
				ang = rotate / 180 * Q_PI;
				sinv = sin(ang);
				cosv = cos(ang);
			}

			if (vecs[0][0])
				sv = 0;
			else if (vecs[0][1])
				sv = 1;
			else
				sv = 2;

			if (vecs[1][0])
				tv = 0;
			else if (vecs[1][1])
				tv = 1;
			else
				tv = 2;

			for (i=0 ; i<2 ; i++)
			{
				ns = cosv * vecs[i][sv] - sinv * vecs[i][tv];
				nt = sinv * vecs[i][sv] +  cosv * vecs[i][tv];
				vecs[i][sv] = ns;
				vecs[i][tv] = nt;
			}

			for (i=0 ; i<2 ; i++)
				for (j=0 ; j<3 ; j++)
					tx.vecs[i][j] = vecs[i][j] / scale[i];

			tx.vecs[0][3] = shift[0];
			tx.vecs[1][3] = shift[1];
		}

	// unique the texinfo
		f->texinfo = FindTexinfo (&tx);
		nummapfaces++;
	};
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
goldenboy
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel
Contact:

Re: Quake .map format versus .Map 220 format

Post by goldenboy »

Just saw this again and wish to comment.

Valve 220 map format deserves to die a fiery death, at least where Quake mapping is concerned.

Reason: If I use Radiant, and another guy on the team uses Worldcraft, I cannot load his map into my editor even if I'm trying to debug a global problem (since I also do game design and coding). This is simply due to the fact that Valve 220 format was meant for Half-Life and Radiant (naturally because of its lineage) uses standard Quake .map files.

Same goes for the use of Half-Life wad3 format in Quake mapping (worldcraft again). Die in a fire, Half-Life formats.

It creates communication problems between mappers, and massively hinders the workflow in a team, or when person B tries to edit person A's released map source.

That is a breaking flaw that makes Worldcraft a culprit in any Quake map-related cooperation or when map sources are passed on. Worldcraft only got so popular among Quake mappers because cooperation between them is rare. But no man is an island and problems are just waiting to happen.

Use of Valve 220 (i.e. Half-Life) map format in Quake should be discouraged, not encouraged. That at least is my opinion, and I deal with the problem regularly.

Edit: I would actually go so far and say that Worldcraft itself should die in a fire. This because it is closed source, which means it can never be updated or expanded or augmented to support new features or new map formats. This was one of the problems when we discussed BSP2 - we could not use anything like Quake 2 surface flags etc. because we could not change the map format. Because we had to keep it worldcraft-friendly. In other words, Worldcraft directly acts to prevent progress regarding map formats and features because it is a black box. The Valve 220 map format is an annoyance that pales in comparison to this.
Arkage
Posts: 66
Joined: Thu Nov 19, 2009 4:17 pm

Re: Quake .map format versus .Map 220 format

Post by Arkage »

I am going to have to stand up for World craft here. Out of all the map ed that I have tried, I can't say any of them trump WorldCraft.
I will admit that using it for Quake mapping is a pain, (converting texture to wad3 just to place them) but the fact that people go through all this just prove it does have something to offer.
It has by far the best UI and has the smallest learning curve that i have seen. less time learning a program, more time mapping :D

I will admit it is annoying that it is closed source, it would have been great if we could add features and enhance it but, sadly not.
Maybe an open source clone would be something to consider?
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Quake .map format versus .Map 220 format

Post by leileilol »

Not only is there a Worldcraft vs. Radiant problem, there's also QuArK vs. Radiant problem because of QuArK's self-promoted so-called "float precision" which regresses compatibility more than anything else. This'll cause problems for even id Tech 3.

Besides, if someone prefers and insists Valve 220... then where the hell are you recruiting from!?

I do use Worldcraft myself - but only the 1.x versions, never any Half-Life ones, which are just dolled up HL exclusive 1.6 versions really, with a revamped 3d preview.
i should not be here
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: Quake .map format versus .Map 220 format

Post by ceriux »

i know if you use hammer 3.5 (the last hl1 version) you can even view models with in the editor. i'm with arkage , an open source clone of it would be amazing. (with supports for making and compiling quake,hl1,and rmq maps?! <3) the editor is very easy to use and has great tools for making complex brushes with ease. plus to mention leilei also seems to have a point. your editor also has problems working with other editors as well, so how can you bash worldcraft/hammer?
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Quake .map format versus .Map 220 format

Post by leileilol »

ceriux wrote: plus to mention leilei also seems to have a point. your editor also has problems working with other editors as well, so how can you bash worldcraft/hammer?
That wasn't my point. My point is that editors regress so they become bad for a development pipeline. Using editors intended for entire games is one way for a bad one. My point about QuArK was a different one where regressions in 'enhancements' also break a pipeline.
i should not be here
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: Quake .map format versus .Map 220 format

Post by ceriux »

fair enough, but i was still able to pull my point out of what you said. which is also still valid...
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quake .map format versus .Map 220 format

Post by Baker »

I don't like the idea of multiple .map formats for a single game. When I first started playing around with mapping, I liked Worldcraft 1.6a the best. However, the software 3D rendering often became slow. But the real pain was trying to rotate an object and then the textures getting massively screwed up and no way to fix. At that point I was like "Why am wasting 1 hour on trying to realign these textures? This is a waste of time." ---> Worldcraft 3.3

Long term I'm not saying I think Worldcraft 3.3 is "great" or anything, but yet it is the one I myself can easily and happily use for my own private mapping. I think Worldcraft is easily understood in about 5 minutes, really.

I do not know if the "classic" .map format actually can support texture rotation correctly in any form. Something I want to learn more about as time goes on. If it can, I liked to be able to back convert. If it can't, I'd like to be able to forward convert.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
hogsy
Posts: 198
Joined: Wed Aug 03, 2011 3:44 pm
Location: UK
Contact:

Re: Quake .map format versus .Map 220 format

Post by hogsy »

I remember reading somewhere that the original .map format doesn't support texture rotation :wink:
negke
Posts: 150
Joined: Wed Apr 16, 2008 5:53 pm
Contact:

Errrrr

Post by negke »

I do not know if the "classic" .map format actually can support texture rotation correctly in any form.
I remember reading somewhere that the original .map format doesn't support texture rotation
Have you ever played a custom Quake map???
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Errrrr

Post by Baker »

negke wrote:Have you ever played a custom Quake map???
Well, that's not playing the .map format. That's playing a compiled .bsp. And aguirRe added a lot of enhancements for the input in txqbsp.

If I recall, you use Quark and txqbsp.

Maybe you are benefitting from "non-original" enhancements while you are making your fine maps, but said enhancements work so well together you don't realize it? :D
txqbsp changelog wrote:* Support for enhanced texture positioning in QuArK.
* Support for Valve 220 map format, e.g. from Hammer.
* Support for Q2/Q3 map format, e.g. from GtkRadiant.
* Support for floating point coordinates in map files (e.g. from QuArK).
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
negke
Posts: 150
Joined: Wed Apr 16, 2008 5:53 pm
Contact:

Well, duh

Post by negke »

I don't use Quark and I don't use any non-standard map format. Qbsp only translates the brush information into bsp/quake-compatible data.
So, of course does the classic map format support texture rotation. Only id didn't seem to have used it in the stock maps.

You wrote it yourself: (x1 y1 z1) (x2 y2 z2) (x3 y3 z3) texture x-shift y-shift angle x-scale y-scale
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Well, duh

Post by Baker »

negke wrote:texture x-shift y-shift angle x-scale y-scale
translation: texture x-shift / texture y-shift
rotation: angle
scale: x-scale y-scale

So translation, rotation and scale are all present. It would seem that everything is present to render the texture in any orientation. Except this kind of sticks out ...
http://www.gamers.org/dEngine/quake/QDP/qmapspec.html

x_off - Texture x-offset (must be multiple of 16)
y_off - Texture y-offset (must be multiple of 16)

rot_angle - floating point value indicating texture rotation
x_scale - scales x-dimension of texture (negative value to flip)
y_scale - scales y-dimension of texture (negative value to flip)
There has to be a weakness somewhere and it might be the offset then. Or maybe it is still possible, but some sort of scaling trickery has to enter the equation to pull it off.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
negke
Posts: 150
Joined: Wed Apr 16, 2008 5:53 pm
Contact:

Re: Quake .map format versus .Map 220 format

Post by negke »

Wait, what exactly is your problem? That properly aligned textures got misaligned again at some point? The thing with Quake textures in a .map is that, unlike in Doom, they are fixed with the grid, not the surface. This means if you move a brush (or face), the texture will not move with it and has to be realigned manually. This is even more visible (and complicated) with rotated textures. Is it this behavior you meant? WC3.3 may have texture-locking enabled by default, so it might have seemed like it was a problem specific to 1.6 or the old map format.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quake .map format versus .Map 220 format

Post by Baker »

1. Well, for one I'm trying to understand why they even would have made the 220 map format or the Quark format.
2. And second, I want to convert 220 format back to original Quake format.

Not because I like the idea of Worldcraft 3.3 map format --- I don't --- but because at the moment some people use it and there is a .map incompatibility issue between different editors that leileilol and goldenboy mention.

At first I was rather muddy on the differences in the formats. But it is becoming a bit more clear. I hadn't considered the grid issue, I thought that just applied to brushes?
negke wrote:Is it this behavior you meant?
Yeah, heh.
negke wrote:WC3.3 may have texture-locking enabled by default, so it might have seemed like it was a problem specific to 1.6 or the old map format.
In Worldcraft 1.6, you can't do texture lock and rotate a brush and expect the textures to still be aligned properly. At least in my experience, that's why I switched to 3.3 way back when.

But it is looking less like a characteristic of the map format and more like just a missing editor feature.
negke wrote:The thing with Quake textures in a .map is that, unlike in Doom, they are fixed with the grid, not the surface. This means if you move a brush (or face), the texture will not move with it and has to be realigned manually.
^^^^ That. Ok, I remember something about that. Without Ben Jardrup around Func talking about this stuff, it has been a while since I read that. And Googling around for info is rather hit and missing finding incomplete documentation.

That is very helpful information. Thanks!
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply