Okay so I'm betting I am not the only one dealing with this crap. Anyone with extensive knowledge of hammer has seen this and I am just going to go and call it a Damaged brush.

Perfect blocks and square and rectangles, all immune to this. Now you go and create something like a cylinder or a torus, save your file, re-open it later......YOU GET THIS CRAP RIGHT HERE!!! The corners that are supposed to connect in the exact same place?! They just friggen rip apart like pieces of paper flapping in the wind, leaking out the map and letting you peer inside of a non-hollow chunk of your hard work like someone took a knife and stabbed your .bsp

WHY DOES THIS HAPPEN!?! I spend so much time fixing this crap!

Did you try to check integrity of Portal 2 Authoring tools files ?
I must say that hammer editor breaking some of the solids for no reason is a common problem.
Did you got an error that you have bad solids on your map while trying to open ?

Yea recently I've been having that issue with toruses, except they just get deleted.

even my cones/spikes get deleted as invalid brushes

@Fracture: that is totally normal, don't freak out Hammer tends to snap all vertices to the grid, and even if you used a legit type of brush like a torus or a cylinder, it must put each of your vertices IN one of the Hammer grid's crossing lines. You'll notice a significative difference if you make something and tie it to a func_detail than if you tie it to a func_brush: you'll see it more deformed if it's a func_brush than if it's a func_detail, it seems that Hammer is more permissive with details since they won't be parented or move.

Think that you can't have floating vertices in the Hammer grid, but only those snapped to the grid.

There are some tricks though:

• you can make whatever shape, an arch or cylinder, at a really big size, making it to fit to the Hammer grid, and then to scale it (Ctrl+M > Scale) down to a smaller size, in many cases Hammer leaves it without change even though it is very small.

• I discovered that you are allowed to clip a brush using the clipping tool as long as the clipping line joins 2 legit points in the Hammer grid, even though after cutting you leave some vertices floating in the air and not snapped to the Hammer grid.

• and remember to tie your brushes to func_details everytime you can instead of other brush entities since they are less deformed by Hammer.

I already have been snapping the displaced vertices to the grid in order to fix them AND turned anything that isn't a world brush into a func_detail, but one torus seems to defy your logic, as well as the flashlight I implemented from Aperture Halloween. I turned it into a func_door_rotating for more dynamic effect.
I notice the deformation occurs after reloading saved files.

I dont see why they keep shifting and diverging even after I snapped them back to grid

Yes, I know what you mean, and it's how Hammer acts, it's normal. I've made many convoluted brushes (semi-archs and cones) and played with the vertex and clipping tools and with these brushes position on the map, and even putting manually all vertices where I thought that was their right place and always in a given Hammer grid node, after reloading the map I can check how Hammer made it a mess.

Have you tried making that torus much bigger and then rescaling it down by any chance?

If you can't eventually work with it, I could turn it into a custom model for you, just let me know the dimensions and send me a pm with the textures in the case they're custom ones

One important thing to know is that brushes saved into VMFs don't ever actually store vertexes. Instead they store planes, which are basically a flat surface extending indefinitely in all directions. The intersections of two planes define edges, and the point where three intersect are vertexes. This is why you can't have concave brushes. With very complicated angles the angles likely end up with slight inaccuacies due to a loss of precision when storing the angles it needs. When Hammer reloads your map, it has to recompute the vertexes, but positions them slightly wrong and off-grid wrecking your solids.

This animation shows how a cube is read out of the VMF planes.

right now I have a flashlight decompiled from Aperture Halloween that could be turned into a model. I was looking through GameBanana for stuff before and wasn't certain how many files were compatible with portal 2