title: TV6
author: tiglari

There are lots of possibilities, but the particular one I went with
is what I call 'QuArK tv6', since it's based on using six numbers as
the value of a 'tv' specific (texture vector) to specify the three
texture points in a coordinate system for the face plane (only six
rather than nine number needed because the plane is 2-dimensional).
One reason for doing this is that it's relatively easy to convert from
the six number representation to the nine number representation that's
expected by other parts of QuArK.  So if you look more closely
at TFace.GetThreePointsT, you'll see that if the tv specific is found,
then the 2-number point specifications in the face coordinate system
are transformed intto 3-number specifications in the map coordinate
system, whereas if no tv specific is found then the threepoints and
mirror bit are used (old representation).  TFace.GetThreePointsUserTex
(which is what Python .threepoints(2) calls) then just uses whatever
GetThreePointsT provides without caring where it comes from.
GetThreePointsUserTex also has an option to either keep the origin of the
texture coordinates roughly in the middle of the face, or not do this.

So much for reading; setting the texture is done by SetThreePointsUserTex,
which handles the scaling.  this calls SetThreePointsEx, which checks
whether the texture threeoints actually manage to define a plane (taking
a cross-product, see below), returning true if they do and false if
they don't (I don't think we need this check anymore, but am leaving it in
for now, and then calls SetThreePointsT which now sets the tv spec,
coincidentally erasing the 'm' specific if this is present, since
we don't need it any more.  Unless of course we're writing the Quark etp
format, in which case TFace.SimulateEnhTex generates old-style
threepoint-and-mirror bit information.

So one leftover question is how is the face coordinate system generated?
Basically by the same scheme as used in the brush-primitives representation
in GtkRadiant, implemented in the function GetAxisBase,
which basically amounts to finding a horizontal vector that lies in the
face, then taking the perpendicular to that that lies in the face.
In QuArK Python, the function quarkpy.qeditor.bestaxes does something
very similar, but the reason for using the GtkRadiant function here
is to be able to write the 'brush primitives' format consistently with
what the GtkRadiant tools expect.  To make a coordinate system we need
an origin as well as the axis vectors (see <ref>src/math/vectors</ref>
for more on the philosophy of vectors); for this we use the first of the
threepoints.

So the new texture scheme is extremely incremental, in the sense that
a face is left in the old representation until its texture is dragged,
and then it changes to the new.  One reason for this is that that even
if there's some mistake it can't happen that somebody's total map will
be trashed, there can only be problems with the faces actually worked on.
The downside is a certain amount of cruft, perhaps someday this could be
eliminated.

A final point is that there is are methods TFace.SetThreePointsEnhEx and
TFace.RevertToEnhTex, callable from Python by enhrevert, just in case.

The last thing that had to be done to make the new scheme work properly was
in the TFace.Deplacement method. which applies linear transformations to
faces, where the code setting the mirror bit is removed, since it is no
longer necessary.  The first version of the new scheme had a problem in
that I didn't check for the InverseOrientation property (the linear mapping
mirror-flips things), so that the brushes all got turned inside out).