Page 1 of 2

Quake .map format versus .Map 220 format

Posted: Fri Jan 13, 2012 7:28 am
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++;
	};

Re: Quake .map format versus .Map 220 format

Posted: Thu Feb 09, 2012 8:29 pm
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.

Re: Quake .map format versus .Map 220 format

Posted: Thu Feb 09, 2012 10:10 pm
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?

Re: Quake .map format versus .Map 220 format

Posted: Fri Feb 10, 2012 1:56 am
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.

Re: Quake .map format versus .Map 220 format

Posted: Fri Feb 10, 2012 3:08 am
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?

Re: Quake .map format versus .Map 220 format

Posted: Fri Feb 10, 2012 4:57 am
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.

Re: Quake .map format versus .Map 220 format

Posted: Fri Feb 10, 2012 6:29 am
by ceriux
fair enough, but i was still able to pull my point out of what you said. which is also still valid...

Re: Quake .map format versus .Map 220 format

Posted: Mon Feb 13, 2012 6:53 am
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.

Re: Quake .map format versus .Map 220 format

Posted: Mon Feb 13, 2012 10:45 am
by hogsy
I remember reading somewhere that the original .map format doesn't support texture rotation :wink:

Errrrr

Posted: Mon Feb 13, 2012 12:39 pm
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???

Re: Errrrr

Posted: Mon Feb 13, 2012 6:49 pm
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).

Well, duh

Posted: Mon Feb 13, 2012 6:58 pm
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

Re: Well, duh

Posted: Mon Feb 13, 2012 7:16 pm
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.

Re: Quake .map format versus .Map 220 format

Posted: Mon Feb 13, 2012 7:27 pm
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.

Re: Quake .map format versus .Map 220 format

Posted: Mon Feb 13, 2012 7:37 pm
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!