2025.8.2 has introduced 'space ants' to curved geometry

[Strideh]

Some geometry that was welding fine in 2025.8.1 now seems to be creating 'space ants' in 2025.8.2, possibly due to the new mesh generation.

2025.8.1

2025.8.2

I have attached the brushwork for you to try, sorry it's a zip but even isolated it was too long to paste as a code block. I've noticed this around a couple of other similar curves in my map too.

brushwork.zip

[LogicAndTrick]

I think the easiest way to handle this would be to add some rounding logic when vertices are generated:

func generate_face_vertices(brush: _BrushData, face_index: int) -> PackedVector3Array:

	# ...snip...

	# round results to 2 decimal places
	for i in winding.size():
		winding.set(i, winding.get(i).snappedf(0.01))
	
	return winding

This has potential to cause other issues but given the modern guidelines of mapping on the grid it may be good enough.

[LogicAndTrick]

Another option is to do the winding calculations using double precision which is not all that nice and would have worse performance, but gives 4 digits of precision instead.

In gdscript, floats are double precision, but Vector3/PackedVector3Arrays are single precision. (https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#float) Which means a custom vector object would be needed to do the calculations in double precision.

Rough version, re-implementing the engine code at: https://github.com/godotengine/godot/blob/825ef2387f87de1c350696886e6c50b039204cef/core/math/geometry_3d.h#L480

class Vector3d:
	const EPSILON : float = 0.0001
	var x : float
	var y : float
	var z : float
	func _init(x_ : float, y_ : float, z_ : float) -> void:
		x = x_
		y = y_
		z = z_
	static func from(vec : Vector3) -> Vector3d:
		return Vector3d.new(vec.x, vec.y, vec.z)
	func to_vector3() -> Vector3:
		return Vector3(snappedf(x, EPSILON), snappedf(y, EPSILON), snappedf(z, EPSILON))
	func dot(with : Vector3d) -> float:
		return x * with.x + y * with.y + z * with.z
	func distance_to(plane : Plane) -> float:
		return dot(Vector3d.from(plane.normal)) - plane.d
	func subtract(with : Vector3d) -> Vector3d:
		return Vector3d.new(x - with.x, y - with.y, z - with.z)
	func add(with : Vector3d) -> Vector3d:
		return Vector3d.new(x + with.x, y + with.y, z + with.z)
	func multiply(by : float) -> Vector3d:
		return Vector3d.new(x * by, y * by, z * by)

func generate_base_winding(plane: Plane) -> Array[Vector3d]:
	var up := Vector3.UP
	if abs(plane.normal.dot(up)) > 0.9:
		up = Vector3.RIGHT

	var right: Vector3d = Vector3d.from(plane.normal.cross(up).normalized())
	var forward: Vector3d = Vector3d.from(right.to_vector3().cross(plane.normal).normalized())
	var centroid: Vector3d = Vector3d.from(plane.get_center())

	# construct oversized square on the plane to clip against
	return [
		centroid.add(right.multiply( _HYPERPLANE_SIZE)).add(forward.multiply( _HYPERPLANE_SIZE)),
		centroid.add(right.multiply(-_HYPERPLANE_SIZE)).add(forward.multiply( _HYPERPLANE_SIZE)),
		centroid.add(right.multiply(-_HYPERPLANE_SIZE)).add(forward.multiply(-_HYPERPLANE_SIZE)),
		centroid.add(right.multiply( _HYPERPLANE_SIZE)).add(forward.multiply(-_HYPERPLANE_SIZE))
	]

const POINT_IN_PLANE_EPSILON : float = 0.00001

func clip_polygon(polygon : Array[Vector3d], plane : Plane) -> Array[Vector3d]:
	const LOC_INSIDE : int = 1;
	const LOC_BOUNDARY : int = 0;
	const LOC_OUTSIDE : int = -1;
	
	if polygon.is_empty():
		return polygon
	
	var location_cache : Array[int] = []
	var inside_count : int = 0
	var outside_count : int = 0
	
	for i in polygon.size():
		var v : Vector3d = polygon[i]
		var dist : float = v.distance_to(plane)
		if dist < -POINT_IN_PLANE_EPSILON:
			location_cache.append(LOC_INSIDE)
			inside_count += 1
		elif dist > POINT_IN_PLANE_EPSILON:
			location_cache.append(LOC_OUTSIDE)
			outside_count += 1
		else:
			location_cache.append(LOC_BOUNDARY)
	
	if outside_count == 0:
		return polygon
	elif inside_count == 0:
		return []
	
	var previous : int = polygon.size() - 1
	var clipped : Array[Vector3d] = []
	for index in polygon.size():
		var loc : int = location_cache[index]
		if loc == LOC_OUTSIDE:
			if location_cache[previous] == LOC_INSIDE:
				var v1 : Vector3d = polygon[previous]
				var v2 : Vector3d = polygon[index]
				
				var segment : Vector3d = v1.subtract(v2)
				var den : float = Vector3d.from(plane.normal).dot(segment)
				var dist : float = v1.distance_to(plane) / den
				dist = -dist
				clipped.append(v1.add(segment.multiply(dist)))
		else:
			var v1 : Vector3d = polygon[index]
			if loc == LOC_INSIDE and location_cache[previous] == LOC_OUTSIDE:
				var v2 : Vector3d = polygon[previous]
				var segment : Vector3d = v1.subtract(v2)
				var den : float = Vector3d.from(plane.normal).dot(segment)
				var dist : float = v1.distance_to(plane) / den
				dist = -dist
				clipped.append(v1.add(segment.multiply(dist)))
			
			clipped.append(v1)
			
		previous = index
	return clipped

func generate_face_vertices(brush: _BrushData, face_index: int) -> PackedVector3Array:
	var plane: Plane = brush.faces[face_index].plane
	
	# Generate initial square polygon to clip other planes against
	var winding: Array[Vector3d] = generate_base_winding(plane)

	for other_face_index in brush.faces.size():
		if other_face_index == face_index:
			continue
		
		# NOTE: This may need to be recentered to the origin, then moved back to the correct face position
		# This problem may arise from floating point inaccuracy, given a large enough initial brush
		winding = clip_polygon(winding, brush.faces[other_face_index].plane)
		if winding.is_empty():
			break
	
	var result : PackedVector3Array = PackedVector3Array()
	for v in winding:
		result.append(v.to_vector3())
	return result

[RhapsodyInGeek]

This would probably have to go all the way back to the parser, since the 64 bit float values get converted to 32 bit Vector3 components that then get turned into Planes, and that's where all of the data comes from for GeoGen.

			# Retrieve plane data
			var points: PackedVector3Array
			points.resize(3) 
			for i in 3:
				tokens[i] = tokens[i].trim_prefix("(")
				var pts: PackedFloat64Array = tokens[i].split_floats(" ", false)
				var point := Vector3(pts[0], pts[1], pts[2])
				points[i] = point
			
			var plane := Plane(points[0], points[1], points[2])
			brush.planes.append(plane)

Recreating the Vector3 and Plane classes to use doubles seems like it might not be a bad idea, but it'd have to start in the Parser.

That all said, we'd prefer to solve this using Godot's built-in data structs if possible.

CC: @sinewavey your input is more valuable than mine here

[RhapsodyInGeek]

@Strideh just pushed a PR that should help take care of this. It's basically an implementation of @LogicAndTrick 's first suggestion. You can check it out here: e38ce93

I'm going to leave this issue open however until we get a more complete solution to this.

[sinewavey]

@Strideh just pushed a PR that should help take care of this. It's basically an implementation of @LogicAndTrick 's first suggestion. You can check it out here: e38ce93

I'm going to leave this issue open however until we get a more complete solution to this.

I do think this is worth investigating first before reimplementing double vec3/planes, especially as there isn't an easy way to get godot to use doubles for those without compiling locally with the correct compiler flags (far beyond the scope of what I would expect people to do for the addon!)

that said, this is definitely going to be a bit of a tough fix, especially if simple snapping isn't enough

[Strideh]

@Strideh just pushed a PR that should help take care of this. It's basically an implementation of @LogicAndTrick 's first suggestion. You can check it out here: e38ce93

I'm going to leave this issue open however until we get a more complete solution to this.

Sounds good! Testing the snap solution does fix most cases, though they required an epsilon of at least 0.05. There's one case I couldn't eliminate by adjusting the epsilon to any value.

However in this case I modified the splits with a straight corner and that did take care of it. So it seems like some extreme/odd angles can still summon the dreaded ants, even with the snap, however it's at least manageable now with some smart building.

[LogicAndTrick]

This would probably have to go all the way back to the parser, since the 64 bit float values get converted to 32 bit Vector3 components that then get turned into Planes, and that's where all of the data comes from for GeoGen.

Yeah, this would likely be the ideal case, and from what I can see TB does the same thing. But the biggest precision loss with floats is when math is done with them - e.g. creating a big winding and then clipping it. So using doubles during clipping would likely handle the majority of issues, and then updating the parser might cover any remaining problems.

[RhapsodyInGeek]

@Strideh latest update has changed this feature. As of 7e61c62 you now set this as an entity property, default is _vertex_merge_distance but can be changed in Map Settings. A base class for this property is provided and included with the default definitions. Should help in instances where you need more granular tuning from entity to entity.

[Strideh]

Just a follow up to this. I've been testing the limits with some fairly detailed geometry and abusing the new per-brush phong to round corners on curves, and so far the most consistent results I'm getting are with a snap distance of 0.0625. Though I can get away with 0.125 on larger, simpler geometry in some cases. I guess this makes sense given the power of 2 grid sizes.

Arguably I might be doing things func_godot wasn't intended to a lot of my curved geometry dips as low as 0.125 units in TB, and I imagine once I it goes down the 1/32 scale precision becomes pretty dang important. @LogicAndTrick has explained to me that floats should neatly divide by 2 so a snap epsilon following that principle probably makes the most sense.

Unfortunately there's still the odd time where no snap epsilon I try will eliminate minor gaps, even though I'm quite sure my geometry is all on grid. I suppose that is where 64 bit precision might help, but at the very least I think a snap epsilon of 0.0625 should probably be recommended.

EDIT:
@LogicAndTrick has also suggesting I try changing the hyperplane constant to 4096, at least for my case with a small map, and it has further eliminated a number of ants and even improved some phong generation on troublesome corners here and there. Still not completely eliminated but at the very least in my case a big improvement.

It might be beyond scope but I wonder if exposing the hyperplane value to users in the map settings is a good idea?

[segfaultxavi]

My map (created with TrenchBroom) uses a grid of 1.
The new default value for _vertex_merge_distance of 0.0625 snaps all vertices to grid 2, which causes all kinds of havoc.
Changing the default to 0.03125 fixes my map.
I think this default makes more sense, since TrenchBroom warns if your vertices do not snap to grid 1, but I don't know about other editors.

Edit: My Inverse Scale Factor is 32, which corresponds to a minimum vertex distance of 0.03125. Maybe the default should be 1/InverseScaleFactor ?

[jondecko]

I spent some time exploring the space ants within my project this evening. I enabled MSAA (8x), within the viewport I am rendering to, and the ants disappeared. Solution came from this thread here ( https://www.reddit.com/r/godot/comments/1p3pl6w/whats_with_this_weird_tearing_on_the_edges_of/ ). Not saying it is the ultimate "fix" but it did get them to go away.

I was able to re-create the ants with some very simple geometry. Created a simple room with 4 walls and a ceiling/floor. Then I took one of the walls and extruded the wall inward to have the wall remain but be composed of different brush sizes. I made a room dark by turning off the environmental ambient light. The ants would appear pretty consistently on the vertical edge of the wall made of multiple brushes.

I really don't know how the internals of the mesh creation works (though I have looked), but is it possible that the vertices are correctly merged but the edges are fighting?

[RisingThumb]

Anti-aliasing basically samples nearby pixels to determine what the current pixel should look like basically "blurring" over sharp edges. I'd expect this to also work for FXAA, TAA and other anti-aliasing solutions. It's not really an acceptable solution though imo because those gaps still exist in the mesh geometry and will probably cause problems with light leaks and gaps in shadows. Additionally any anti aliasing option is additional performance overhead and if it's a graphics setting a user can change and turn off it's not something you can rely on. It does make it look less bad though I agree. If you want to get rid of them, you're better off tweaking the vertex merge distance until almost all space ants are gone.

As for why this happens, it seems to be related to floating point precision going from 32 bit to 64 bit. See this explanation earlier #157 (comment)