Plane aligning CTRL+M Created 11 years ago2013-06-06 22:12:01 UTC by Striker

I recently investigated some things about .vmf files. I accidentally noticed that when modifying in Hammer some vertices, even if they appear to be in an exact position, the actual plane parameters are quite odd.

For instance, we have this 64x64x64 cube, positioned at 0,0,0 with its bottom-left corner.Here you can see the plane parameters of the top and bottom face:Now I'm going to rotate this on Y by 180 degrees:The plane parameters now look like this:What's happening here? I believe this doesn't affect how map compiles( although... the compiler interprets nothing else but this .vmf!). But if this happens on most of the brushes, and I use quite a lot CTRL+M, I can start to imagine why sometimes vrad simply stops compiling without reason(I have talked about the issue of vrad.exe stopping the compile on bigger maps( CPU 0%) several times).

what happens if you control-B it after rotating (snapping brush to grid)
?

Also.

What made you investigate? J/w

Hmm... Never used CTRL-B. Will check tomorrow, it's late now.

I wanted to know how solids are represented in a .vmf, and while tinkering with them in hammer and then visualizing in notepad++, I noticed the thing.

Hammer uses floating point types for coordinates, this includes the points used to define planes. The "rotation around the origin" algorithm uses the sine and cosine functions (which often depend on PI and are fractional) as well as translation to the zero coordinate before the rotation is performed. (This can also be done with matrix operations which is similar, but can be done in one operation instead of three.)

Because the floating point data type has unavoidable rounding issues that accumulate over time, each operation adds tiny variations to the final value that make the value wander a little bit each time the value changes. This can often be avoided by adding some rounding to the values every time the value changes, however I don't think Hammer does this.

In your example above, the transformation that's applied makes some of the the vertex values change just enough to show in the VMF, but only by 0.00000559506. Which obviously isn't much, and will probably round to zero when you compile. When saving the VMF, Hammer just uses the first three points in the face to define the plane and it applies no rounding, which is why you see the rounding errors appearing in the VMF.

I would suspect that Hammer might do a bit of rounding when loading VMFs, because the only way to reconstitute a solid when loading a VMF is to perform the plane intersection algorithm which introduces a whole bunch of floating point rounding issues by itself.

I don't know the exact behaviour of Hammer in regards to rounding, but some interesting experiments you might want to try include:
1. Try Tetsuo's snapping to grid method (however I believe that this snaps on the brush level rather than the vertex level, which means it might not change the plane values)
2. Open your second VMF with the tiny rounding issues, resave it as a new VMF, and compare the two (to see if any rounding values change when the plane intersection is done)
3. Move only one vertex in the cube a bit to force it back on the grid (if Hammer does absolutely no rounding at all this would create an invalid solid as one point in the quad is ever-so-slightly off-grid) and do a "check for problems"
4. Save the map from test 3 to a new VMF and compare it to the original

And so on. Rounding in general is much better in Hammer 4 - if I recall, it was much more of an issue in Hammer 3 (which is why HLfix exists).

I've had more troubles with this in Hammer 4 than I ever did with Hammer 3. I only recall having the issue in 3 when I had copied a large amount of brushes at a time, and even then, it only really happened when copying more complex geometry.

It's true suture, but the tradeoff is you can build many many many more brushes in hammer 4 than you ever could in 3x.

also as I've said in the past, these "floating vertices" rarely cause visual errors in-game so they can be largely ignored.