   How to calculate the texture axis for a .MAP file brush?
  Hello,I am adding .MAP exporting support to my gameSpace level exporter (currently it only exports to Game Studio .WMP), I have read the MAP file specs, and done some progress, however I am stuck on the "texture axis" generation part, I have searched the posts and most of them talk about converting those to UV coordinates (the opposite of what I need) or how to generate the geometry out of the plane points.to help understand my problem, here is a quote from the Map spec:"Brushes consist of four or more faces. There is no limit to the number of brushes that can be in an entity.Brushes are always convex, which is a very useful property (as will be seen later on). Instead of beingdescribed as a set of polygons, brushes are described as a set of faces. An example face is:( 0 64 64 ) ( 64 64 64 ) ( 64 0 64 ) BCRATE02 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1It starts with a three point plane description. Then the texture name is given. Next the U and Vtexture axis are given. Then the texture rotation is given (which is useless information because thetexture axis are already rotated). Last, the U and V texture scale is given.I will clarify the texture axis. The first one is the U axis and the second one is the V axis. The first threenumbers of a texture axis give the texture axis’ normal. The fourth number gives the texture shift (oroffset). Each texture axis can be imagined as a plane."The texture axes are the numbers between the brackets, and the part I am having problems with is with generating the Normal, which I understand seems to be a vector pointing on the direction the U and V values flow to respectively, but, how do I calculate that out of the plane points (or te actual face, or polygon) and the UV values I have for the face?hmmmm not sure if that made much sence, but please help 
  bump ;  there s a documentation about it available somewhereemail me and ill send it to youbtw i would stick with GTK or CoD Radiant instead of Worldcraft, since the radiant format is slightly different and you can get the radiant source code to easily update the editor to your needs, assuming your got used to the code *pure c mixed with some c++* ;  Thanks, I will email you,I have downloaded the source to GTKRadiant as well was QRandiant, the problem there is that they use the old MAP format, the one that did not had texture axes, so not really useful, QuArk does use the new "220" format, but its delphi, so I dont even know where to start looking, specially since I don''t have delphi. ;  In the "world" mode the UV axis are chosen (as in Quake) from the three axis-aligned planes based on the normal of the polygon. For example, if the absolute value of the normal''s Z is higher than those of X and Y, the UV axis are on the XY plane (U=X, V=Y). The texture rotation number is for rotation along this plane. The UV axis themselves aren''t rotated as you rotate the texture in Hammer, which keeps it deterministic.When you change the texture mapping to "face" mode it calculates a new set of UV axis by taking the closest axis-aligned plane as above, and aligning it to the surface normal (I assume a couple of cross products). ;  Thanks,I found out how to get the initial UV normals with the following code (may it help someone in the future):   if((fabsf(Normal.x)>fabsf(Normal.y))&&(fabsf(Normal.x)>fabsf(Normal.z)))    { vUNormal.x=0; vUNormal.y=1; vUNormal.z=0; vVNormal.x=0; vVNormal.y=0; vVNormal.z=-1;    }  else if((fabsf(Normal.y)>fabsf(Normal.x))&&  (fabsf(Normal.y)>fabsf(Normal.z)))    { vUNormal.x=1; vUNormal.y=0; vUNormal.z=0; vVNormal.x=0; vVNormal.y=0; vVNormal.z=-1;    }  else    { vUNormal.x=1; vUNormal.y=0; vUNormal.z=0; vVNormal.x=0; vVNormal.y=-1; vVNormal.z=0;    }Where Normal is a Vector class (or struct) variable that contains the plane normal, vUNormal is the texture U normal and vVNormal is the V Normal.Even though this is ok to get the initial (default) values I would still be interested on calculating the actual values given that I have a fully texture mapped cube, I am codding so the user gets to set the values by hand, but such an automated functionality would be nice to have non the less 