Texture coordinate question

[Willem]

OK, calling all engine/math gurus!

I have a lot of cool ideas for stuff to add to my Quake level editor, ToeTag, but they all hinge on having really good texture locking capabilities. I figure that there is one key to the kingdom here and it's this:

How do I convert from 0-1 texture coordinates back into Quakes pan/rotate/scale coordinates?

So:

1. is this possible, mathematically speaking?
2. How do I do it? Assume that I'm a math illiterate (not a bad assumption, believe me) and show me the code to do it.

Any takers? I can't even get a return email from Carmack on this so I assume that it's a quagmire of nightmares but I figured that if anyone would know it would be you engine coders!!

HALP!!1!

[Error]

I have a suggestion for Toetag... port it to Windows so I can use it!

[metlslime]

willem, it's not always possible to take arbitrary U,V coordinates for each vertex, and generate a quake-style projection for them. This is because quake's projection system allows translate, scale, and rotate, but doesn't allow you to add (or subtract) a "skew" effect.

However, you should be able to do a "best fit" by using the UV coordinates of just the first two vertices (which are enough to encode translate/rotate/scale but not enough to encode skew.)

[metlslime]

and as for how to do it, here's a general description but you'll have to work out the details:

1. quake uses one of three axial projections, depending on the facing angle of the polygon: top (XY), front (XZ), side (YZ). When a face is exactly 45 degrees between two of these, there's some arbitrary but consistent rule for picking one.

2. the default projection is scaled to the texture dimensions, so 1 texel = 1 unit of world space in the two dimensions used by that projection.

3. quake applies the user-supplied projection by first translating, then scaling, then rotating.

4. to work backwards from UVs to projection, you will need to compare the vertex coodinates in UV space to their coordinates in default projection space. Default projection space is the XYZ coordinate mapped into the correct axial projection space, and scaled according to the texture dimensions.

5. rotation is the angle between the vectors defined by the verts in both coordinate spaces. scale is the ratio of distances between the verts in the two coordinate spaces. translate is the offset between one of the verts in one space, and the same vert in the other space.

6. Be sure to remove the effect of each transform before calculating the next one.

For reference, check out BuildSurfaceDisplayList in the glquake source code, this demonstrates converting quake projections into UV coordinates (referred to as S,T in the code.)

[Willem]

Thanks metl!

Yeah, I know it will never be perfect due to a lack of skewing but it would certainly open up possibilities if I were to be able to get this working. I'll make a note of what you said and try it out the next time I'm in there.

I'm guessing that what I'll end up with eventually will be a "close in Quake terms" conversion - it won't be perfect but it will be as close as Quake will allow.

For reference, check out BuildSurfaceDisplayList in the glquake source code, this demonstrates converting quake projections into UV coordinates (referred to as S,T in the code.)

Yes, I have that routine working. That's how ToeTag does a lot of it's internal texture mapping. Going from Quake->UV is a known quantity - it's going from UV->Quake that's confusing. :-/

Again, thanks for the reply and I'll give your ideas a shot...