Map2Dif Alpha ver 0.96

#81 @Everyone

GarageGames is a dedicated and growing team of 15+ professionals and many more outside contractors and associates and dedicated users spread out over many various projects. We all work very long hours and weekends and try to go above and beyond to help out as many people as possible. Unfortunately, when we have to please so many people, we can't get to the needs of every one individual all the time, but we do read everything and are aware of everything you guys say, the community is the lifeblood of GarageGames.

In Torque Engine alone, a lot of people don't realize how much process has to go into something before we can release it to the public. I constantly hear people "Wow this is great, this should go into HEAD!" but many people aren't aware as to A) The programming team has to make sure this is actually a beneficial fix, B) make sure this works without breaking anything else in the tens of thousands of lines of code in the engine, C) make sure it's cross-platform, D) find time to do this without stopping current development and many more tests. So something that may take an average programmer 5 minutes to drop into their codebase takes us days to verify if we just work on that. When a few thousand people give you their money, you can't just put out updates without being sure you won't make the situation worse, it's a risk GarageGames just can't take.

I also hear a lot "Why isnt' X problem fixed?" Well, chances are it will be in time, but when you have thousands of people saying that sentence simultaneously, you can see how it can be hard for a small company such as GarageGames to please everyone instantly at the same time.

However, we do make ourselves available. We do write down the problems, they do get put in the que of stuff to get done. It's not that we are ignoring them, it's that we haven't gotten to them yet. These thing stake time! Everyone here goes to great lengths to make themselves available to the community. Jeff personally reads every single message that is posted on this site, he never skips a beat. I answer every single email I get, even those in foreign languages. ;)
I freely give out my instant messenger name, and sit on IRC and the forums to make myself available to all who have questions. Fruitbat, I have answers your questions numerous times, and even drew up diagrams at 3am to help you understand something in this very thread, so your not being ignored, and the fact is I'm not alone, pretty much everyone at GarageGames has the same practices in communication as I do.

This version of Map2DIF is an alpha release, and we appreciate all the feedback we've recieved in this thread! However, it's still an alpha release in which we released simply on the basis of good faith to help those who were desperately in need of quick & better solution! This is not a final release canidate. There are still problems. We know there are problems but we are working on them. We appreciate everyone helping us find these problems, but we want to make sure that every individual that starts to use this Alpha release goes uses it expecting there to still be some problems left.

The Torque Art pipeline is one of our primarily goals on things to improve in 2005 with our first step in this year being the new & improved showtool. We are aware of problems with exports, map2dif, and many other art-pipeline related things and we are continually working to improve these situations to benefit all of you.

We hope you stick with GarageGames and have faith in us to be able to address some of the problems many of you experience with TGE. We are listening to you guys and we want the engine to be improved as much if not more then anyone else, but we have a lot of stuff to do on top of Torque itself, so just give us some time to work on it. You won't be disappointed I'm sure! :-)

#82 When I first started working at GarageGames six months ago, I was blown away by how incredibly brilliant everyone who works in this building is. Everyone here could easily be off at some mega-corporation raking in the big $$ but instead (much to the dismay of our bank accounts) we all work here because we all believe in good games, and what we are trying to do with leveling the "technology playing field" so YOU guys can breed good games!

However, (despite what you may hear on the forums!) we are still very much human, and are prone to just as many mistakes as everyone else if not more! Yet we believe in what we are doing here and believe in Torque and most of all we are dedicated to it more then anyone else.

Following the evolution of Torque since GarageGames first opened it's incredible to see how far the engine has come in such a short time, and a lot of that is due to you guys, the community! Seriously, we want the the same things you guys want! And... in the end, you all will all get everything you want, but just give us some time to get you there! :-)

#83 I'd really like this thread to return to it's original state. I think it was a good idea to release map2dif alpha but I don't like it when a topic sways like this way.

When I saw this thread I got very excited and must say I was waiting impatiently for an update. So I downloaded it, checked it out for a little, noticed it found 2 geometric errors on 2 of my maps that the previous map2dif ignored, fixed them, and quietly reverted back to using the old map2dif happily simply because I acknowlegded that this was an alpha release and needed a lot more work before it got completed.

I should've commented about it but there wasn't much else I could offer programming wise. But just going through this and seing how much work already had gone into it got me going and could easily keep me for another month or two before another status update.

Everybody is working hard and doing a great job. GG staff, Matt and other associates, Fruit, rest of us, so let's just keep going. I think this is the best community with the fewest angry arguments compared to other ones, let's keep it this way.

Just my thoughts.

Nick

#84 I know everyone has a million things to do, I'm in the same situation (hence the under desk line that started this). This thread (apart from the last day of ranting) has been more useful than any other so far. Tims 'Ninja Leaks' explanation, Matts MUCH BETTER map2dif, and the explanation of various problems has made me much more aware of the issues.
As for testing the new map2dif I have run 30+ maps through it so far and its cleared up a lot of the strange errors so well done Matt. I'm still spending time trying to nail down the brush configurations that still cause problems before I report.

Possible problem
I assume this is just me but I can't get the new map2dif to find the textures under hammer. Have you got it working Tim? If so, can you post the cmd please :) The old ones work fine.

EDIT: Got the new QuArK :)

#85 I have been testing the QuArK with the higher precision numbers. It does solve a few issues with compilcated brushes but does not affect the lighting issues, so no quick fix :(

I have been comparing the hammer and quark map files for the same brushes. The only major difference is the order the faces are written out and the texture transformation are always more detailed (floats)

QuArK
{
( 1184 -704 -144 ) ( 864 -704 -144 ) ( 864 -832 -144 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 864 -832 -144 ) ( 864 -832 -128 ) ( 1184 -832 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 1184 -704 -144 ) ( 1184 -704 -128 ) ( 864 -704 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 1184 -832 -144 ) ( 1184 -832 -128 ) ( 1184 -704 -128 ) HAZARDTAPE [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 864 -704 -144 ) ( 864 -704 -128 ) ( 864 -832 -128 ) SHTEX512 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 1184 -832 -128 ) ( 864 -832 -128 ) ( 864 -704 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
}

Hammer
{
( 864 -832 -128 ) ( 864 -704 -128 ) ( 1184 -704 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 864 -704 -144 ) ( 864 -704 -128 ) ( 864 -832 -128 ) SHTEX512 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 1184 -832 -144 ) ( 1184 -832 -128 ) ( 1184 -704 -128 ) HAZARDTAPE [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 1184 -704 -144 ) ( 1184 -704 -128 ) ( 864 -704 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 864 -832 -144 ) ( 864 -832 -128 ) ( 1184 -832 -128 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 864 -704 -144 ) ( 864 -832 -144 ) ( 1184 -832 -144 ) HAZARDTAPE [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
}

Anyone got any ideas on whether this would affect map2dif? The only thing I can really think is that QuArK edited maps go off the grid easily. I've noticed that if you draw a brush to the grid and immediately do snap to grid, it moves half a unit, I'm pretty sure thats got to be the source of the problem. I'll chase the guys up again.

#86 I think most of the tension was just miscommunication, probably due to the lack of sleep of everyone in the situation lol :) ... Don't think Fruitbat was trying to come accross harsh, just some humor, even if a bit dry humor (ok so I have a weird sense of humor too)...

I for one (and I know many many others will stand with me on this) appreciate all the work you all at GG put in... can't even begin to put it to words the oppurtunity you (as well as the community that assists) have given me and my team to use a AAA kick ass engine to make a game from a starting group of four of us, self funded. The level of quality in the game just wouldn't be possible without GG...

I am also extremely glad you released this alpha version, because even with the issues in the alpha release this is still better than the previous verions (in my opinion)... heck, most of these errors are ones that have been there in the past... the new map2dif is AMAZING Matt... great work! Can't even imagine the code you've gone through to get it to this point, all the work you've been doing is much more than just appreciated, lol when my team gets our first full game released I'm going to tattoo all of GG names' into my arm or something lol... ok for lack of poisoning and pain maybe not that, but at the least I'm going to have to get a GG hat shirt or something to advertise you all like crazy!

Thanks again and these early versions are wonderful... my teams game is still a long way from being released so even if there are issues with it still this gets us past some of the most annoying issues with map2dif... Thanks!

#87 @FruitBat
If you build a brush with the vertices on grid and then select the brush and snap to grid, its the centroid of the brush being snapped to grid, not the vertices. If you rotate a brush, you are rotating around the centroid, so unless its square, the vertices will go off grid. If you slice a brush at an angle, the new vertices wil more than likely be off grid. Point is, there are a lot of ways to make that happen; Quark is doing what it's supposed to do. But let me add the caveat which I've stated in numerous posts here: the QuArK 6.4 alpha and versions of 6.3 prior to the final were NOT stable with respect to vertex control. Simply dragging a vertex could get it off grid; I worked with Tiglari a long time to resolve that issue because as a mapper, it brought me to a total standstill. Which version of Quark are you using BTW?

Regarding the order of the faces, not an issue.

@Matt Fairfax
I have a question regarding the translucentDetail resource: is there any plan to incorporate transparency in the TGE map2dif? Or, since we now have TSE, is that a bygone issue? I have integrated the translucentDetail into quark/tge/map2dif (as well as the radiosity/lighting_pack resources); the translucentDetail resource creates an object that is not a member of the BSP tree and therefore is continuously rendered--this can cause a dramatic slowdown. Also, there have been several crossover threads dealing with integrating the pathedInteriors in a more mapper friendly way (in particular regarding the retooling of the addChildren function. Are there any plans from GG to incorporate a functional moving interior in the TGE version of map2dif or will this effort go to TSE?

Thanks for all your efforts!

#88

Quote: the QuArK 6.4 alpha and versions of 6.3 prior to the final were NOT stable

Damn, damn, damn :(

#89 FruitBatInShades,
The drifts causing the light leaks occur when two brushes should be sharing the same plane (ie butted up against each other or in line with each other) but end up being slighty off in the export. You would need to look at several brushes together to see the differences (and work some math to generate the plane equations).

Desmond,
I intend to have moving platforms and transparency working with TGE interiors but I can't offer a solid timeline for that yet.

All,
Thank you for the kind words.

Anyone who is having trouble with textures,
If you look at the first line of the output from the new map2dif you shoudl see something that says:

mapFile = blah, modPath = blah2

The new map2dif uses the resource manager to find the textures (so the same rules as Torque). It will search from the directory the mapFile is in all the way up to the modPath directory. You can override the modPath directly with the -t option. If you hand in a fully qualified map name (C:\torque\example\starter.fps\data\interiors\blah.map) it will expect the textures to be in that directory. The alpha is also generating a console.log in the same directory as the exe which you should be able to open and see how the resource manager tried to load the texture.

#90 @Matt,
Are you saying the drift is being generated by map2dif by introducing differences in the plane equations for two adjacent brushes? I can see that happening; without having looked specifically at that section of code, would it be possible to have a "closeness" filter. I can't imagine why anyone would want a tiny difference between two vertices so, for example, if two vertices are within a certain tolerance, consider them the same for the purposes of creating the lightmap?? Just a thought; kind of like epsilon.

Second, is it also possible to search sideways (for example a folder called "textures" at the same level as a "maps" folder?

#91 Desmond,
It is a little more subtle than that and ultimately isn't map2dif's fault. If you look at a brush in a .map file you will see that it is just a list of planes each being exposed as 3 points on the plane. Now in theory, any three points on the plane should always generate the same plane but in practice floating point differences can cause two different sets of points that *should* define the same plane to define ones that are very close but slightly different. Quark is really bad about picking points for a shared plane that end up generating two different planes (one for one brush and another for the other brush). Without looking at the code for Quark, I would guess that they use three vertices from a face and simply write them out (with rounding). Since these vertices might have minute differences from brush to brush and might be rounded in a different way you get tiny little errors that add up even on shared faces. Hammer on the other hand uses a very different algorithm to convert its brush faces into planes (you'll note it always outputs integers...which is a fun mathematical excercise). I also suspect that Hammer represents the brushes as a set of planes internally. These leads to a much higher fidelity where a shared plane almost always calculates out to be exactly the same in map2dif. Unfortunately, Quark's integer output rounds things even worse than its floating point output.

Now, I have done things to help reduce the impact of these minute variations like "filtering" the planes and the vertices with lower tolerances. This is one of the things that makes map2dif plus so much "nicer" than map2dif. The first phase was mainly focused on the geometry creation pass in map2dif while the collision, hidden surface removal, visibility/zoning, and lighting passes were left nearly untouched. I did lower some of those tolerances but there is a lot more work to be done in that area.

I do plan to add an automatic search for a "textures" directory but it didn't make it into the alpha.

#92 @Desmond:

Just to clarify, are you saying that QuArK 6.3 final produces less errors than 6.4? So we would be better off using 6.3 final?

@Matt:

0.96 seems pretty solid. I have been working with hammer and it hasn't messed up once on structure (you know about the texture thing). It even pulls back most of the bad QuArK maps. So it really does look like QuArK is at fault on most of these issues.

Good Job

You were talking about three points. There are a number of options that I don't understand in QuArK, could these be at fault and what would turning them off do? It may be good to find someone who has a good QuArK setup and see what options they use.

'Use Integral vertices as threepoint'
'Quantize angles'

are both on in my setup. I've also said before that in 6.4 non-integral faces are generated all the time. You can't create a simple map without getting loads of these (no idea what they are :0D ). Fix non-integral vertices clears these up and you immediately get less errors.

#93 Love the .log file...really gives some good information...

Just loaded the Game Level Builder 2.2 script to my Max 7... created a few test maps, exported to map and dropped that map into the map2dif alpha ... converted just fine, works like a charm. Haven't tried texturing in max yet though, took it from GLB to Quark (to create doors and texture) then to Torque, works fine as well. Only thing I need to remember is keeping the scale in mind while in Max... very easy to zoom out and create a level that wont run through the new (or old) map2dif because of the generated lightmap (at least thats the error that is presented)... but this is only on huge levels that seem small in Max

#94 @Matt

Quote:Without looking at the code for Quark, I would guess that they use three vertices from a face and simply write them out (with rounding)

QuArK outputs integral or floating point threepoints depending whether you check that option in the configs.

The Valve Mapversion 220 map format used by WorldCraft 3.3 uses texture-scale representation that is quite close to the texinfo_t data structure used by qbsp. This consists of 2 axes lying in one of the three planes normal to the axes, plus offsets, and the formula for computing the texture coordinate of a point xyz on a face is:

u = x * u_axis.x + y * u_axis.y + z * u_axis.z + u_offset
   v = x * v_axis.x + y * v_axis.y + z * v_axis.z + v_offset

(Max McGuire's Quake2 BSP file format tutorial on
www.flipcode.com)

Additional notes from QkMap.pas in the ReadSquareTex4 procedure:
U/V Axis/Shift are straight from the 4-vectors, param[3] is rot which is ignored (implicit from the axes), while param[4,5] are UV scales. The axis-vectors are of length one, and you divide by the scale to get the corresponding .bsp-type axis vector. (Zoner's HL tools source, textures.cpp).

Thought this might be of interest to you.

#95 @FruitBat
Yes and No; we need to be very specific in what we call 6.3 or 6.4 because like TGE, QuArK is constantly going thru revisions.

Just prior to 6.3 Final there were problems with vertex drift. 6.3 FINAL version fixed that.
After 6.3 final, the 6.4 alpha was released for testing and introduced other issues.
However, the most recent snapshot appears to be working well. This is the 1-29-2005 snapshot from: dynamic.gamespy.com/~quark/ It also allows loading PNG files directly into the add-ons and are viewable in the texture browser (which they were not in the 6.4 alpha release).

Give it a try.

#96 Desmond,
Yes, I know Quark can output floating point or integral...I was theorizing on how it generates those 3 points. Hammer generates them very well while Quark generates them poorly.

I've never seen an issue with the texgen calculations for either app so I'm not sure what the significance of the rest of your post is?

#97 @Matt: There is a fairly common error with Valve220 Maps (don't know about other format) from quark where texture corrdinates get screwed up if they are rotated textures on faces that are rotated in multiple dimensions. I have run into this a few times when creating roofs and other similar things.

I'll see if I can put together a map to reproduce it for you.

#98 @Matt
The reason I brought up the texture coords is that's where quark gets the plane coords. Because I haven't looked at this in a long time I went through QkMapPoly.pas in the quark source and extracted pertinent sections to illustrate the process of exporting the brush descriptions as best I can understand it. This assumes that:
a) Not writing floating point coords
b) Not using integral vertices as threepoints
c) MapFormat=V220Type

Also, I have chopped out large sections of code to make this clearer (for me if not anyone else LOL)

In QkMapPoly.pas in procedure TPolyhedron.SaveAsTextPolygon
1. First, the face coordinates are grabbed from the texture vector with this procedural call: F.SimulateEnhTex(P[1], P[3], P[2], EtpMirror);
(I'm ignoring the mirroring aspects and highlighting in bold what I believe are the pertinent areas.)

{ returns etp threepoints and mirror bit }
procedure TFace.SimulateEnhTex(var V1, V2, V3: TVect; var Mirror: boolean);
var
  TexV: array[1..6] of Single;
  TexP: array[1..3] of TVect;
  V1b, V2b: TVect;
  R: TDouble;
begin
  if LoadData and GetFloatsSpec('tv',TexV) then
 [b] begin
    GetThreePointsT(V1, V2, V3);
    V1b.X:=V2.X-V1.X;
    V1b.Y:=V2.Y-V1.Y;
    V1b.Z:=V2.Z-V1.Z;
    V2b.X:=V3.X-V1.X;
    V2b.Y:=V3.Y-V1.Y;
    V2b.Z:=V3.Z-V1.Z;
    R:=Dot(Cross(V1b, V2b), Normale);[/b]
    if R > rien2 then
      Mirror:=False
     else
     begin
       V1b:=V2;
       V2:=V3;
       V3:=V1b;
       Mirror:=True;
     end;
  end
  else
  begin
    GetThreePoints(V1, V2, V3);
    Mirror:=TextureMirror;
  end;
end;

The GetThreePointsT function call above is listed below:

{ returns the tv-defined threepoints if they exist, otherwise the standard-ones as flipped by texture-mirror }
function TFace.GetThreePointsT(var V1, V2, V3: TVect) : boolean;
var
  TexV: array[1..6] of Single;
  P0, P1, P2, T1, T2, T3, TexS, TexT, V, Norm : TVect;
begin
  [b]if GetFloatsSpec('tv',TexV) and GetThreepoints(P0, P1, P2) then
  begin
      Norm:=Cross(VecDiff(P1,P0),VecDiff(P2,P0));
      GetAxisBase(Norm, TexS, TexT);
      T1:=MakeVect(TexV[1], TexV[2], 0);
      T2:=MakeVect(TexV[3], TexV[4], 0);
      T3:=MakeVect(TexV[5], TexV[6], 0);
      V1:=Tex2FaceCoords(T1, P0, TexS, TexT);
      V2:=Tex2FaceCoords(T2, P0, TexS, TexT);
      V3:=Tex2FaceCoords(T3, P0, TexS, TexT);
      Result:=true;
      Exit;
  end;[/b]
  if TextureMirror then
    Result:=GetThreePoints(V1, V3, V2)
  else
    Result:=GetThreePoints(V1, V2, V3);
end;

2. Second, the face is stored to a string

Depending on whether we set assumption b:
if UseIntegralVertices then
near-integral vertexes corrected to integrals are used as threepoints

else if ExpandThreePoints then
3point arms are multiplied by a factor of 100 before rounding off.

Since we assumed b:

P[2]:=VecSum(P[1],VecScale(100,VecDiff(P[2],P[1])));
   P[3]:=VecSum(P[1],VecScale(100,VecDiff(P[3],P[1])));

3. Now, the scaling above and the rounding below are where I think one problem might lie (Fruitbat was onto it :))
The plane points are rounded and added to string:

for I:=1 to 3 do
      with P[I] do

        S:=S+'( ';
        [b]R:=Round(X);
        S:=S+FloatToStrF(X, ffFixed, 20, 5)+' ';
         R:=Round(Y);
        S:=S+FloatToStrF(Y, ffFixed, 20, 5)+' ';
         R:=Round(Z);
        S:=S+FloatToStrF(Z, ffFixed, 20, 5)+' ) ';[/b]

4. The texture name is added to the string:

S:=S+NomTex;

#99 5. The texture parameters are now added to the string by a procedural call to Valve220MapParams. I think there is another problem with the call to the write4vect procedure which also truncates the values:

procedure Valve220MapParams(const Normale: TVect; const F: TFace; var S: String);

  procedure [b]write4vect[/b](const V: TVect; D : Double; var S: String);
    begin
     S:=S+' [ ';
     [b]S:=S+FloatToStrF(V.X, ffFixed, 20, 5)+' ';
     S:=S+FloatToStrF(V.Y, ffFixed, 20, 5)+' ';
     S:=S+FloatToStrF(V.Z, ffFixed, 20, 5)+' ';
     S:=S+FloatToStrF(D, ffFixed, 20, 5)+' ';
     S:=S+'] ';[/b]
    end;

begin

  Plan:=PointsToPlane(Normale);
  case Plan of
   'X' : Axis := MakeVect(1, 0, 0);
   'Y' : Axis := MakeVect(0, 1, 0);
   'Z' : Axis := MakeVect(0, 0, 1);
  end;

  Origin:=MakeVect(0,0,0);

  F.GetThreePointsT(PP0, PP1, PP2);

  P0:=ProjectPointToPlane(PP0, Axis, Origin, Axis);
  P1:=ProjectPointToPlane(PP1, Axis, Origin, Axis);
  P2:=ProjectPointToPlane(PP2, Axis, Origin, Axis);

  // D1|D2 = Zoner's TexPt[0|1]
  D1:= VecScale(1.0/128.0, VecDiff(P1, P0));
  D2:= VecScale(1.0/128.0, VecDiff(P2, P0));
  {
        dot22 = DotProduct(TexPt[0], TexPt[0]);
        dot23 = DotProduct(TexPt[0], TexPt[1]);
        dot33 = DotProduct(TexPt[1], TexPt[1]);
        mdet = dot22 * dot33 - dot23 * dot23;
  }

  Dot22:=Dot(D1, D1);
  Dot23:=Dot(D1, D2);
  Dot33:=Dot(D2, D2);
  Mdet:= Dot22*Dot33 - Dot23*Dot23;
 
  {
         mdet = 1.0 / mdet;
         aa = dot33 * mdet;
         bb = -dot23 * mdet;
         dd = dot22 * mdet;
  }

  Mdet := 1.0/MDet;
  aa:=Dot33*MDet;
  bb:=-Dot23*Mdet;
  dd:= Dot22*Mdet;

  QV0:=VecSum(VecScale(aa, D1), VecScale(bb, D2));
  QV1:=VecSum(VecScale(-bb, D1), VecScale(-dd, D2));

  {
    side->td.vects.quark.vects[0][3] 
          = -DotProduct(side->td.vects.quark.vects[0], side->planepts[0]);
    side->td.vects.quark.vects[1][3] 
         = -DotProduct(side->td.vects.quark.vects[1], side->planepts[0]);
  }

  UOff:=-Dot(QV0,P0);
  VOff:=-Dot(QV1,P0);

  UAxis:=QV0;
  VAxis:=QV1;

  Normalise(QV0, S1);
  Normalise(QV1, S2);

  [b]write4vect[/b](QV0, UOff, S);
  [b]write4vect[/b](QV1, VOff, S);

  S1:=1.0/S1;
  S2:=1.0/S2;

  S:=S+' 0 ';
  [b]S:=S+' '+FloatToStrF(S1, ffFixed, 20, 5);[/b]
  { sign flip engineered into Scale }
 [b] S:=S+' '+FloatToStrF(S2, ffFixed, 20, 5);[/b]

end;

6. Finally, the string is output:

Brush.Add(CommentMapLine(Ancestry));
 Brush.Add(' {');

 if g_DrawInfo.ConstruirePolyedres then
   for J:=0 to Faces.Count-1 do
     WriteFace(PSurface(Faces[J])^.F)
 else
   for J:=0 to SubElements.Count-1 do
     begin
       Q:=SubElements[J];
       if Q is TFace then
          WriteFace(TFace(Q));
     end;

 Brush.Add(' }');

Whew, hope this helps shed some light. I will definately be contacting Tiglari about this...in the short term I'm hoping you can create some C++ magic work-around. Let me know if you think the issue is even solvable at your end; if not, I will step up the pace on the QuArK end.

#100 Stupid "Notify me" checkbox suddenly refreshed the page and erased my post. :(

I'll try again, perhaps less patiently this time. ;-)

The new map2dif can't seem to find my textures. I'm using Hammer 3.4 and I keep my configuration and directory structure exactly the same; I just point my configuration to the map2dif_alpha.exe instead of my standard map2dif.exe. It appears to compile fine, but when I load the map to check it out, all the walls are white.

I also tried just running map2dif_alpha from a command line so I could make sure I'm specifying the correct directory for the textures (which is /interiors -- the same as my output directory). Again, it appears to compile fine but when I load the map... white walls everywhere.

The lighting and geometry appear to compile fine. *shrug*

When I switch back to the old map2dif, everything compiles and all textures appear again.

Any ideas what I might be doing wrong?