Dylancyclone
commented
4 years ago Here's what I've found so far:
- The problem is not based on position, as in a converted displacement will have the same orientation no matter where on the hammer grid it is (positive vs negative x/y)
- The problem can be seen with stitched displacements. This means that the converted orientation can be different between displacements that are right next to each other. This makes it real hard to track down the source of the issue since it seems random.
It's really difficult to try and illustrate the issue without going in and actually moving the vertices where they're supposed to go, especially since one or both axis could be flipped. - The
startpositionattribute can be a point literally anywhere in space. Now, this isn't very unusual considering the same thing can happen for brushes (since those points define a line, which goes on infinitely), but it's weird here because it's just a single point in space not connect to the displacement geometry.
...unless the startposition point is on a line formed by the brush that makes up the displacement, rather than the actual displacement. Which would be kind of dumb, and incredibly counter-intuitive, but I guess is a possibility. Which could explain why the problem is worse in decompiled maps since it spits out less user-friendly data.
Sometimes, the orientation of displacements is incorrect. I'm having trouble tracking down the source of the issue, but it seems to occur more often in decompiled maps compared to "raw" vmf maps built in hammer. See an example here: https://youtu.be/3CgoCSRIGqI?t=90
According to the VDC, there is an attribute of displacements called
startpositionthat is supposed to indicate the bottom left corner of the displacement, but unless I'm missing something, this value doesn't seem to be spitting out useful information. (and bottom-left corner relative to what? ) https://developer.valvesoftware.com/wiki/Valve_Map_Format#DispinfoThe annoying part is that the overall dimensions of the converted displacement are correct, it's just the order in which the vertices are loaded that is incorrect. This isn't a problem for square displacements since the converted result can easily be mirrored into position, but rectangular displacements are a little more difficult to fix quickly.