Union Issues when created in script

I am having issues with unions in studio, more specifically in script.

What is happening? There are two issues that are happening, one relating to pathfinding and the other relating to hitboxes.

  1. Hitboxes are inaccurate (20%-30%~ of the time), even when using PreciseConvexDecomposition (or whatever the collision fidelity is called) This typically happens when unioning in script. I am making a game that relies on unions and this is a big issue because when unioning out a piece of a wall to create a door, the hitboxes would mess up.

  2. Pathfinding thinks it can go through unions that were created in script (in-game), which is an issue because pathfinding is a key aspect of my game which uses unions. (This issue usually happens when the part that is being subtracted from size is less than or equal to 0.5)


collision issue

Negate function code: (sorry if there are some variables that i didnt show)

local function negate(v:BasePart,negativeClone)
	repeat wait() until game.ServerStorage.ServerCooldown.Value == 0
	game.ServerStorage.ServerCooldown.Value = 1
	local subtract:UnionOperation = v:SubtractAsync({negativeClone},Enum.CollisionFidelity.PreciseConvexDecomposition,Enum.RenderFidelity.Precise)
	subtract.Parent = v.Parent

	if v:IsA("Part") then
		local clone = v:Clone()
		clone.Parent = v.Parent
		clone.Transparency = 1
		clone.CanCollide = false
		clone.Name = 'hitProtector'

		local pathMod = Instance.new("PathfindingModifier",clone)
		pathMod.PassThrough = false
		pathMod.Label = "Danger"
		pathMod.Name = 'ignoreWall'
	local fake = Instance.new("Part",workspace)
	fake.Name = 'fake'
	fake.Position = Vector3.new(0,10000,0)
	fake.Anchored = true
	fake.Transparency = 1
	local subtract2 = subtract:SubtractAsync({fake},Enum.CollisionFidelity.PreciseConvexDecomposition,Enum.RenderFidelity.Automatic)
	subtract2.Parent = subtract.Parent
	subtract2.Name = v.Name
	return subtract2

Demonstrative Test File:
UnionIssue.rbxl (67.4 KB)

It would be great if you could help.



1 Like

I’ve been having the same issue here, I’m trying to make a House Map Generator with Walls being subtracted for doorways, but the bug shown here is occuring.

Considering I’ve not been able to find a solution to this, I’m pretty sure it is most likely a Roblox Bug with the CSG Engine.

At least there is more proof of this issue happening.

Can you show what’s happening so there is a greater chance that this will get fixed?

1 Like

Sure thing.

I have an example here of a completely normal looking doorway. The doorway union is in bricks. (ignore the selection outlines)

If we turn on the “Show Decomposition Geometry” studio setting, which essentially shows the collisions given for all unions and parts, it looks like this:

As you can see, there is a random wedge blocking part of the doorway. This example is a minor case, but the position and size of this buggy collision triangle is random, so you could get a doorway path that is completely untraversable.

Using Enum.CollisionFidelity.PreciseConvexDecomposition significantly reduces the chance of this happing, but it does not stop it either.

1 Like

Pretty sure this is expected behavior with Unions. The collision geometry is collapsed to reduce physics performance impact. Precise convex decomposition reduces the extent that this happens, but does not completely eliminate it. This is documented.

You should not drill holes in parts using CSG and expect the collision on those holes to be completely accurate. This is a very common problem with people trying to make doorways. You should use a doorway prefab section to splice into the wall, or use three-four parts to create the gap.

I’m doing this inside of a script, which would require alot of math/meshes.

Yes I am aware. That information doesn’t change. This is still expected behavior.

Where is it documented? I wish to see it.

This option is the most accurate representation of collision geometry for complex objects with built-in tolerances to reduce the total number of convex-hulls by compromising on accuracy when justified.

The phrasing of this says (translated to plain english) that perfect precision is not guaranteed. I’ve also seen this mentioned on the forum in an old announcement before.

How would I create a module script that creates hitboxes for unions in that case.

Suggest moving to #help-and-feedback for further questions about your situation.

As far as that question goes: you cannot modify the physics data yourself. You could make the unions for visuals and then approximate the collisions using invisible parts though. Unfortunate and difficult situation, but not much to do about it.

Thanks for the report; We’ll follow up when we have an update for you;