Hammer or Torque wrong vertex

#1 Ok, it's Hammer's fault. I opened the .MAP and there were that vertex mess. I still tried to put the vertices back in the right position, but when I save and load the file again, the error remains.

It's an imprecise plane definition. Did someone have this problem with Hammer? How can I avoid this limitation?

#2 had this problem, but im not sure how to fix it, though i did move vertices then put them back, re-exported and it was fine with no errors, re-check everything try moving them a space over or so

#3 I already did it in the .RMF and in the .MAP, but the vertices are still misplaced.

If somebody wants to help, e-mail me for the .MAP file. It has some floating point values, but not in the troubled brushes.

Also, anybody knows the .MAP file format? The first three parenthesis are the three points describing a plane. Then, we have the texture name. What about those sets of four numbers inside brackets, and the next three numbers at the end of the line? What are they?

#4 Its usually a problem of map2dif. I'm having a ton of problems becuase of this. The map files are right, then after export the .dif shows some errors. Some vertexes are slightly misplaced, but this sometimes cauases leaks, ugly artifacts,.... map2dif should be cleaned up/fixed

#5 No, in my case it's Hammer fault. I was editing the .RMF, wich was correct, then I opened the .MAP and the vertices were misplaced. The error occured even before the Map2Dif compilation.

Those brushes' planes were all non-orthogonal. There wasn't a single orthogonal plane on them. My suspect is that Hammer doesn't deal correctly with it. I avoided this changing the architecture to make the brushes non-orthogonal only from the top or from a side view (never both).

It works now, and maybe this thread will stand here as a bug report or an advice. Hope I don't step on any "surprise" like this again.

#6 WC and QuArK both follow a strict set of rules that don't belong to other 3D game models. One rule you may be breaking is making a concave poly? (can't tell from your post). At any rate, WC allows vertex manip., which can oft lead to bad final maps. QuArK is much stricter: It allows movement of individual vertices, but will force the user to make only correct choices.

It was hard for me to get used to this idea at first, but really, what's easier? Get used to QuArK's choices? or guesswork at trying to get the vertex in the proper position?

--Eric Forhan, MRT

#7 Eric, my brushes are all convex. There isn't any illegal brush, it's not the point. I can't post an image, so it's hard to explain in more detail, but the messed brushes are the ones that has all planes non-orthogonal. If you, or someone else is curious, e-mail me and I'll send the .RMF (correct!) and the .MAP (messy!). It can be useful as a reference of something weird about plane description in Hammer.

Answering your question, I started my work in Quark, but had to move to Hammer due to my vertex manipulation needs. Quark's decision to not allow a single vertex move is the worst in my opinion. Qoole was the best, it allowed single vertex, edge or face move, giving an error message on the illegal cases.

Hammer's freedom doesn't hurt, it's easier to avoid concave brushes than get used to Quark's constraints.

#8 Quark's constraints are working really fine for me...I use vertex manipulation all the time. When this doesn't work, all you have to do is cut the brush sometimes, so you create triangular shaped brushes.... then you can go on with your vertex manipulation. I can't think of anything you can do in Hammer you can't do in Quark. In fact Quark has stuff you can't do in hammer....but that's not really related to Torque as most of these features do not aply to this engine (bezier curves for example).
What bothers me is when creating a 10 side cylinder for example, the vertexes of the sides get moved my map2dif (i guess to fit on a integer grid). Most of the time you don't even notice.... but sometimes its so abvious the structure gets really ugly.

#9 Ward, take a look at the .MAP generated by Quark. Open it in Quark and look at the vertices. Maybe the lack of precision is Quark's fault too.

The three points these editors choose to define a plane are always close to the origin (0 0 0). I can't understand why they doesn't simply choose three of a brush face's vertices to define its plane. It would be all integer values, and no possible error. Maybe their data structures are not based on vertices...

Well, Quark is powerful, I only gave up on it because I was finding no way to slice my brushes to get the right shape.

Of course Quark is powerful, it's written in the mighty Delphi! My speciality. Long live Object Pascal!

I wish I had some clones of myself to do two or three things at a time, like make my game and play with Quark code.

#10 No its really Map2Dif... its a problem everyone is aware of.. but no one really fixes it (or I have an outdated version of map2dif)

#11 Desmond Fletcher could answer this one much better than I(I believe he's even addressed it before). QuArK can be set to allow (or disallow) floating point coordinates. This setting is in "Configuration-->Map-->Options-->'Don't right floating point coords'". (make sure you have this checkmarked on).

Desmond has mentioned there could be a need for making map2dif work with floating points, but beyond that I don't know.

--Eric Forhan MRT

#12 i have this same problem and im know for sure its not problem with hammer or wc - this bug is in conversion tool - "map2dip" is bugged - that is what i think ...

#13 i can say more - after using map2dif i see now the geometry is total not mathing with this what i can see in hammer editor and in torque

#14 Just in case someone digs this old thread up... allow your editor to export floating point units (I'm using Quark) and the mismatched vertices will vanish.