EditableMesh:RemoveVertex on a mesh with 1 vertex causes a 32-bit overflow

Unfortunately, I have no idea what causes this, but it can be reproduced with this code

local eMesh = Instance.new("EditableMesh")
eMesh.Parent = workspace
eMesh:AddVertex(Vector3.new())
eMesh:RemoveVertex(1)
print(eMesh:AddVertex(Vector3.new()))

The returned number is 4,294,967,297, which is 2 over the 32-bit limit (4,294,967,295)

Expected behavior

The vertex ID to be 1, and not a number near an int limit, as this feels like it’s unintended behaviour.

5 Likes

Hi metatablecat, thanks for the bug report.

This is actually expected behavior, although I can see why it seems odd. Vertex ids refer to an internal vertex, but they’re not valid after the vertex has been deleted. As part of the stability, if you delete a vertex and create a new one, it’ll have a new id which is different than the old id.

From lua, it’s best to treat the ids as opaque, because we may change the layout of what is stored in the future. We’ll be adding a function in the future that will let you get the vertex index and version in a more readable form, for debugging purposes.

If you’re curious, internally the way that’s implemented is that we have a 32-bit index, and a version number packed together into a single integer. When the index is reused, the version number increments. This can result in some very large numbers, however a number in lua is a double, which can store a 53-bit int exactly.

But like I said, this will change in the future, so it’s best not to rely on the internals of the current implementation.

3 Likes