Reopening VMF throws vertices off-grid Created 12 years ago2012-10-04 02:30:03 UTC by Archie Archie

Created 12 years ago2012-10-04 02:30:03 UTC by Archie Archie

Posted 12 years ago2012-10-04 03:03:41 UTC Post #310223
Hey, I'm not sure if this issue has been raised already - I tried searching and didn't find anything.
This has been happening to me a lot lately:
User posted image
I take care making perfectly clean, valid brushwork using vertex manipulation techniques that have been common practice since Goldsource days and until fairly recently I've never had an issue. All vertices are on-grid and are perfectly legal when the map is saved, but upon re-opening the .vmf all the manipulated vertices are ever so slightly off-grid making them entirely unmanageable. It's so slight that it looks absolutely fine from a distance and you'd only notice by zooming in.
Absolutely microscopic changes between the points of gridsize 1. For scale purposes, in the screenshot I posted, the image on the right is zoomed right in on gridsize 1. The image on the left is gridsize 32.

This is not overly-complex brushwork, it's made of standard 5-sided tris (inc top and bottom face) and 6-sided rectangles. I could build this identically in Hammer 3.5 and have no problem what-so-ever. It's something Hammer 4 is doing during the save.

This seems to happen pretty much 100% of the time after any form of vertex manipulation and occasionally just from using the clip tool. It's seriously messing me up! Any ideas?
Archie ArchieGoodbye Moonmen
Posted 12 years ago2012-10-04 04:20:54 UTC Post #310224
This is due to how the VMF format works when compared to the RMF format.

VMF looks something like this (sorry if this is a bit wrong, guessing from memory here):
solid {
  face {
    "plane" "(0 0 0) (0 0 512) (0 512 512)"
    "material" "tools/trigger"
    // Blah blah more stuff here
  }
  face {
    // And so on
  }
}
The important thing with this format is that the brush vertices are not actually stored in the VMF format, just the face planes. When Hammer loads a VMF, it performs a plane intersection algorithm to obtain the values for the vertices. Because it uses floating point calculations, you get the small rounding errors you see in your screenshot.

The RMF format, on the other hand, is a serialised binary C++ data structure, the very same structure that is used in the Hammer code for display and calculations. Roughly, it's something like this:
class CMapSolid {
  CMapPlane plane;
  CMapVertex vertices[];
  CMapMaterial material;
  // And so on...
}
This structure of course has the actual rounded values for the vertices and these are used when the map is loaded. You still get rounding errors when the vertices are off-grid and when converting to the MAP format (which is what HLFix partially mitigates), but if your vertices are on the grid you won't ever get any rounding issues in Hammer 3.

As a bonus, let's look at the MAP format (too lazy to look it up but it's something like this):
(0 0 0) (0 0 512) (0 512 512) "AAATRIGGER" [0 1 0 0] [0 0 1 0]
The MAP format only stores the planes, just like the VMF format. The interesting thing about this is the MAP format is what the Goldsource compiler actually uses to compile the map, which means that the advantages of the RMF format are lost when compiled. This is still better than Hammer 4, where the precision of the vertices are lost in your VMF file, rather than just in the compiled BSP. If you saved your Goldsource maps in the MAP format instead of the RMF format, Hammer 3 would have to do the intersecting planes algorithm to calculate the brush vertices, resulting in the same off-grid issues that happen when using the VMF format.
Penguinboy PenguinboyHaha, I died again!
Posted 12 years ago2012-10-04 09:02:21 UTC Post #310226
Oh... so it'd always happen before compile regardless, even in goldsource?
Hrm. Not entirely sure where that leaves me. Is it a non-issue?
Archie ArchieGoodbye Moonmen
Posted 12 years ago2012-10-04 12:28:43 UTC Post #310228
I don't know enough about the compile process to know for sure, but I would guess that at some point the small rounding errors are corrected or smoothed out during compile- or render-time. I can't say for sure but I would speculate that these issues are unavoidable. I would have thought Hammer would round the numbers a bit (at least to the closest 0.125 units or something) but I guess it doesn't.
Penguinboy PenguinboyHaha, I died again!
Posted 12 years ago2012-10-04 14:52:20 UTC Post #310232
Hammer has been doing that since day one, when the Source SDK first came out.
I haven't mapped enough to tell if this will fix the issue, but you can try opening the file hammer.dll with a hex editor and search for (%g %g %g) (%g %g %g) (%g %g %g) and replace it with (%f %f %f) (%f %f %f) (%f %f %f). Again, I'm not sure if this will do anything. Make sure you keep a copy of the modified hammer.dll file in case the SDK decides to replace it with an unmodified dll.
You must be logged in to post a response.