Hammer adding random vertices to brushes

OK, this is getting really fucking irritating, but hammer seems to think its a good idea to add random fucking verts to the edges of my brushes with no conceivable reason.
I’ve encountered this bug in every version of hammer, but it has really started popping up in the CS GO authoring tools after Hammer, in its usual and predictable shittyness crashed after I changed a prop_physics_multiplayer to a prop_static, after realizing I had used the wrong model.

Here is an example:

I need a 90 degree curve, so instead of using 6 brushes, I thought it was a good idea to make a 24 sided cylinder, and then resize the remaining quarter to fit my needs. Now this is were the weirdness happens. Sometimes it happens when I’m working, and I notice that the lines aren’t lining up perfectly, or after I load the map again.

So in preparing some screenshots to compare, I found that the problem is with the clip tool, and I have no clue as to why it’s like this, so maybe one of you guys could explain it to me, because its really god damn annoying.

Posting pics now.

OK in picture one, I am aligning the clip tool to cut the cylinder in half like I described above, and have the two clip nodes placed inside the shape.

In picture 2 I zoom into the offending vertex that the cut is being made along, as you can see, the clip line follows the grid perfectly

In picture 3, I instead place one clip node on the vertex, and the other node outside the shape, but for some reason it does not follow the gridline, and instead veers off and eventually connects with the symmetrical vert on the other side of the shape. If you aren’t zoomed waaay waaay the fuck in it looks like it is doing its job fine.

Pretty much show this in picture 4:

So, am I using the tool wrong? In my mind it should not matter how the nodes are placed as long as they are on the grid. Any help would be appreciated.

It seems odd that the clip tool would lose focus on the shape you’re trying to cut even if its on the same gridline.

This is essentially the result of the above scenario

zoomed in

Are you using face split? If so, you might be running into this problem.

[editline]17th January 2013[/editline]

Nvm, OP edited.

Could you post the VMF before and after splitting?

I’ll create a new one, since the VMF this is part of a larger project I want to show you guys next week.

[editline]17th January 2013[/editline]

OK, here is the .vmf with the random vert splitting I’m encountering.

http://www.fileswap.com/dl/zHKjGZItls/

I get this problem as well I think it’s something to do with how the vertex data is stored in the map file.

There’s a valve page which describes the problem: https://developer.valvesoftware.com/wiki/Reshaping_Solids scroll down to complicated shapes.

There’s an Interlopers thread about it as well: http://www.interlopers.net/forum/viewtopic.php?f=2&t=35762&sid=cf47f0a0a52c84ab50e9170ac265d573

I keep seeing this problem pop up all over the place but I don’t know if anyone has figured out how to stop it.

It’s called decimal loss, and it’s also the reason why stuff like this happens, no matter how well you align your brushes:

https://dl.dropbox.com/u/17850283/hammer_decimalloss.png[/T]

Coming from a GoldSrc mapping background, I know Vluzacn made a fix for Hammer 3.4, but I doubt it’d work for the Source Hammer (couldn’t find it to test).
By the way, there’s no reason whatsoever for decimal loss to occur on simple geometry like cylinders, so I think something with the primitive generation is going wrong; it’s either that or the clipping tool.

[editline]18th January 2013[/editline]

https://dl.dropbox.com/u/17850283/hammer_decimalloss_plane.png

Motherfucker …
Just checked the VMF you sent me, and that’s the face that was causing trouble. So yeah, something did go wrong with the clipping tool. You’ll just have to deal with it, I guess.

[editline]18th January 2013[/editline]

In order to avoid the problem you were having, instead of splitting the bottom brush like in the left picture, leave it whole like in the right picture:

[T]https://dl.dropbox.com/u/17850283/hammer_decimalloss_vs1.png[/T] [T]https://dl.dropbox.com/u/17850283/hammer_decimalloss_vs2.png

Alright, thanks guys for helping me out!

I really appreciate you going to all the trouble to explain this to me!

One last question; how would changing the brushes on the ground prevent the vertex issue on the cylinder?

EDIT: nvm read the article, figured it out.

The problem is more than that. Hammer stores brush faces in plane format, instead of the much more precise vertex format. Brush faces are basically infinite planes that are chopped when they intersect with another face plane on the same brush. No borders are defined, so where the verticies on the brush end up are anyone’s guess, because they’re never in the same place.

The VMF format is so imprecise that every time you save the map, the entire map is corrupted slightly. It’s also further corrupted by rounding by the compile tools, which is why when you measure world geometry with traces, they’re never the same.

The patch that Vluzacn made forces Hammer to save maps in vertex format, instead of plane format. It is possible to do the same with Source Hammer, but the problem would be that the vertex format doesn’t support displacements.

The problem with the clipping tool is that when you clip something, it converts whatever you’re clipping to vertex format, uses a terrible algorithm to clip and then coverts back to plane format.