Pixel Gap Problems

[umbral shell]

I've tried to remake this about 10-15 times but seems to always come out with a gaps in-between some of the brushes.

I have noticed that the vertex tool is problematic in Hammer++, so I avoid it at all costs (unless I am forced to use it). These ramps in particular were made by rotating each brush by 6 units and connecting them together by alt, which is a more tedious process, but is how I made surf ramps in the past. This wasn't an issue in regular Hammer, but for some reason these gaps are created after compiling, and I am wondering why that is.

[umbral shell]

Note: If I move the ramp to a new location inside of Hammer, the object will be affected by gaps on other areas.

[warped pollen]

does it happen if you make all segments 1 func_detail

or maybe fix it so theres no gaps then use propper to make the ramp a model

[umbral shell]

Yes, it happens no matter what.

[umbral shell]

Hm, I guess I could try this

[pearl bane]

They’re created because the way geometry works in hammer is different than in the engine, in a hammer vmf it is essentially not saving your vertices but the planes of each face and making them intersect to form brushes

If you are alt-rotating brushes you are going to run into this problem a lot

[umbral shell]

I see. Well, this seems to be more of an issue in Hammer++ than in regular Hammer, to my knowledge. In the older version of Hammer, these gaps were never created after compiling, if alt was used to join ramps together.

[limpid zenith]

This is just not a good use case for brushes in general. If you really want to use brushes, I would try separating the brushes so that a face is always a triangle, but that would only help little. Another thing, and idk if this is still an issue in hammer++, but repeated loading and saving makes the brushes lose precision more and more. You could therefore use instances for complicated objects like this, to avoid repeated saving. The most definitive and simple solution is to use a model. But of course, that comes with lighting downsides.

[mild nest]

save-load precision loss isn't a thing in h++

[royal pewter]

h++ saves with more precision than stock hammer, and it is possible for that to desync at extremities because vbsp reads the imprecise data

in tools -> options -> hammer++ you can disable "use precise vertex data" so that it only loads the imprecise data

but obviously that means it will be much harder to edit these after a save and reload

i believe slammin vbsp fixes this by calculating brushes at double precision

if you are compiling with strata compilers, you should ask them to also look into this, because it is a VBSP bug

[umbral shell]

Interesting. I never knew this, thank you for the tip. What specifically is "harder" when it comes to editing these brushes by disabling precise vertex data?

[royal pewter]

they dont join up together at corners anymore

[umbral shell]

I see. In other words, turning off the precise vertex data will revert Hammer back to the stock version of Hammer, and the trade-off is save-load precision loss?