So you cannot create even one?
No I can but it caps out at 7.
Can you try without AddNormal, SetFaceNormals and SetFaceColors?
1 Like
Just tried. Didn’t work. same error after 7 EM.
1 Like
I tried reducing the triangle count of the Editablemeshes, now it did a lot more, but that still defeats the purpose and it still errored after some.
Can you share your verticies array? Of course if you want.
1 Like
Its generated on runtime, its marching cubes. When I set chunk size to 16x16x16, 119 EM before limit. When I set it to 64, 6 EM before limit.
(Ignore copy looks, in terrain application these would all be different)
How many triangles are in one mesh? I will try set the same amount.
1 Like
ok so i tried with this and it looks like there is total triangles limit for static meshes and its around 72 000
local asset=game.AssetService
local main=script.Part.main
for i=1,3600,10 do
for j=1,10,1 do
local cl=main:Clone()
cl.Parent=script.Part
cl.Position=main.Position
cl.Name='v'..j+i-1
main.CFrame*=CFrame.new(0,1,0)
end
main.CFrame*=CFrame.new(1,-10,0)*CFrame.Angles(0,math.rad(1),0)
end
main:Destroy()
for i=1,15,1 do
local editable=asset:CreateEditableMesh()
local array={}
for i=1,#script.Part:GetChildren(),1 do
array[i]=editable:AddVertex(script.Part['v'..i].Position)
end
for i=1,3600-11,10 do
for j=1,9,1 do
editable:AddTriangle(array[j+i],array[j+i-1],array[j+i+9])
editable:AddTriangle(array[j+i],array[j+i+9],array[i+j+10])
end
end
local static=asset:CreateEditableMeshAsync(Content.fromObject(editable))
editable:Destroy()
local mesh=asset:CreateMeshPartAsync(Content.fromObject(static)) print(i)
mesh.Anchored=true
mesh.Parent=workspace
mesh.Name=i
--mesh.Position=workspace.mp.Position
--static:Destroy()
end
Create a part inside the script and then create attachment and name it “main”.
For me loop stops after creating 11 meshes, because of budget limit.
1 Like
Can we hope that you will share information on how to modify the rig’s limbs using EditableMesh and all this would not tear/break/tear off/move to the side or deep into the character?
Your place with the head demonstration is good, but try to do the same with a shortened arm, a modified body or an extended leg.
We are trying to do a normal job on a skinned rig, but without success
1 Like
Do we have an expected date for a fix to the memory issue? a limit of 8 is low, I did a test with my blood splatter and the mesh was around 6kb in size (exporting it as an obj to test, I don’t know of any other better way lmao)
So realistically, an average laptop has around 8b of memory, and lets say that the rest of your game uses around 4 - 5gb, you still got a solid amount of memory for the editable meshes, now with the idea that most editable meshes would follow this 6kb size, you could create almost 166,666 editable meshes before you even reach 1 gb of memory usage. So I do think that the limit of 8 is a bit absurd
1 Like
Is there a way to create from an existing EditableMesh using FixedSize true, that adjusts the size/collisions of the MeshPart? You can edit the vertice positions, and thus change the “size” of the mesh, but it doesn’t actually alter the bound box of the mesh.
Before
After
-- OriginalEditableMesh is what appears in the first image, just a basic 6 sided rectangle.
local NewEditableMesh = AssetService:CreateEditableMeshAsync(Content.fromObject(OriginalEditableMesh))
local MeshPart = AssetService:CreateMeshPartAsync(
Content.fromObject(NewEditableMesh),
{ CollisionFidelity = Enum.CollisionFidelity.Box }
)
MeshPart.CFrame += Vector3.new((i * (LENGTH * 1.5)), HEIGHT / 2, 0)
MeshPart.CFrame *= CFrame.Angles(0, math.rad(0), 0)
MeshPart.Anchored = true
MeshPart.Parent = workspace
-- I use SetPosition on some vertices to adjust some of the faces vertices,
-- to create the triangle edge on the right, but obviously doesn't affect bounding box
Reason for me trying to attempt it this way is due to limits still being super low 
Cause ideally I want players to be creating potentially hundreds of these segments in a single moment.
I’m not sure if this is what you’re looking for, but the way to create new collision geometry from an EditableMesh is to call AssetService:CreateMeshPartAsync. This should work on a FixedSize EditableMesh (here, FixedSize means that the number of vertices, faces, etc. of the mesh stay the same, even though they can be moved around and the physical size of the mesh can change)
So, for example, if you have a MeshPart that is backed by an EditableMesh, you can recompute its collision geometry like this:
local previewMesh = ... -- previewMesh is a MeshPart backed by a fixed-size EditableMesh
-- create a new MeshPart backed by the same EditableMesh
local newPreviewMesh = AssetService:CreateMeshPartAsync(previewMesh.MeshContent)
-- replace the collision geometry, being careful to keep the visual size the same
local renderScale = previewMesh.Size / previewMesh.MeshSize
previewMesh:ApplyMesh(newPreviewMesh)
previewMesh.Size = renderScale * previewMesh.MeshSize
This won’t need to create a new EditableMesh, so you don’t have to worry about the EditableMesh memory budget. It will only update the collision geometry on the MeshPart.
Let me know if you were trying to do something else though
I’m not entirely sure if that’s what I’m needing? I’m just editing the EditableMesh that’s already been applied to a MeshPart. The MeshPart seems to visually change when I move vertices around/etc. But the actual collisions/bounding box does not change
Cause my use case (for when replication finally exists) is players placing walls and walls needing to adjust their collisions as they drag in more walls/etc.
Or even think for example you have a wall placed, then place a door. I’d move the vertices around to allow a hole in the wall, but the collisions would still be the same as the original placed wall. Or would I need to be generated a new EditableMesh in those cases?
Okay, it sounds like the code snippet I provided should work for what you want.
An EditableMesh only contains the mesh data, and is used for rendering.
To update the physics data / collision geometry, you need to create a new MeshPart from the EditableMesh, and either use that new MeshPart directly, or use ApplyMesh to update the collision geometry.
How is there still not a way to read how much memory is available so that we can budget our existing EditableImages accordingly? It’s 2025 and this guess-work is absolutely ridiculous. We have a live game (Draw Me) with >10,000 CCU’s at any given moment, that relies on EditableImage, and we constantly get people complaining about out-of-memory errors. Yet there really is nothing we can do, except try to assume how bad their device is, and thus deliver them a worse experience.
There’s not even ways we could “squeeze” more performance out of this feature, like one can usually do with their code in almost every other programming language on earth, because once again, we’re relying on complete guess-work here. There’s no way to read the memory available, no way to detect an upcoming crash, no way to know that a user left because they crashed from low memory, no way to do really anything except guess. I understand that Roblox needs to set the limits so that they can make as many devices as possible work, but this lack of “data” that we can work with is definitely worse than the alternative. An alternative where we could actually work with the power of the user’s device and cater to their device specifically.
This really limits the usefulness of this feature, and more-so, it is extremely frustrating as a Roblox game developer.
5 Likes
I have gotten a question:
Maybe it’s a good idea to implement Content thing to ViewportFrame? So they will generate Content "image" like EditableImage.
This can be used a lot, if there’s at least 2 ViewportFrames which are used to render absolutely the same object, or white object which can be recolored. This will allow developers to pre-made 20-30 viewport frames and use them when needed with ImageLabels
I myself will benefir from this a lot - I have inventory full of items - most of which can be pre-maded. Mainly, that’s where they will even be used.
Regarding safety, drawing tools, and such: ViewportFrame already can be used for drawing in 2D with parts inside it (tho TextLabel will be much more performant comparing to it (assuming that no Id-verification done)), so nothing new bad can occur.
Raisethe darn mesh limit! Im making a procedural planet system. And i could make these bigger if i had the permissions. (why i wanna make them bigger, well simply because when i stand on them its not exactly a believable planet effect, you can definately notice the curving)
2 Likes
This reaches limits though? Will those limits be removed in the future? Or better control to allow us to duplicate from a base mesh and adjust the vertices, which in turn adjusts the collisions
Worth noting, this my script
local THICKNESS = 0.5
local HEIGHT = 14
local LENGTH = 5
local AssetService = game:GetService("AssetService")
-- Create the original EditableMesh (once)
local OriginalEditableMesh = AssetService:CreateEditableMesh()
local function AddQuad(mesh, A, B, C, D)
local i = mesh:AddVertex(A)
local j = mesh:AddVertex(B)
local k = mesh:AddVertex(C)
local l = mesh:AddVertex(D)
local f1 = mesh:AddTriangle(i, k, j)
local f2 = mesh:AddTriangle(i, l, k)
return { Vertices = { i, j, k, l }, Faces = { f1, f2 } }
end
local hl, hh, ht = LENGTH / 2, HEIGHT / 2, THICKNESS / 2
local LF, RF, LB, RB = -hl, hl, -hl, hl
local B, T = -hh, hh
local F, BK = -ht, ht
local MeshFaces = {} -- Holds face IDs from OriginalEditableMesh
-- Create the 6 sides of the wall segment
local Front = AddQuad(
OriginalEditableMesh,
Vector3.new(LF, B, F),
Vector3.new(RF, B, F),
Vector3.new(RF, T, F),
Vector3.new(LF, T, F)
)
local Back = AddQuad(
OriginalEditableMesh,
Vector3.new(RB, B, BK),
Vector3.new(LB, B, BK),
Vector3.new(LB, T, BK),
Vector3.new(RB, T, BK)
)
local Top = AddQuad(
OriginalEditableMesh,
Vector3.new(LB, T, BK),
Vector3.new(LF, T, F),
Vector3.new(RF, T, F),
Vector3.new(RB, T, BK)
)
local Bottom = AddQuad(
OriginalEditableMesh,
Vector3.new(LF, B, F),
Vector3.new(LB, B, BK),
Vector3.new(RB, B, BK),
Vector3.new(RF, B, F)
)
local Left = AddQuad(
OriginalEditableMesh,
Vector3.new(LB, B, BK),
Vector3.new(LF, B, F),
Vector3.new(LF, T, F),
Vector3.new(LB, T, BK)
)
local Right = AddQuad(
OriginalEditableMesh,
Vector3.new(RF, B, F),
Vector3.new(RB, B, BK),
Vector3.new(RB, T, BK),
Vector3.new(RF, T, F)
)
-- Store faces
MeshFaces.Front = Front
MeshFaces.Back = Back
MeshFaces.Top = Top
MeshFaces.Bottom = Bottom
MeshFaces.Left = Left
MeshFaces.Right = Right
local NewEditableMesh = AssetService:CreateEditableMeshAsync(Content.fromObject(OriginalEditableMesh))
-- Create mesh part in world
local MeshPart = AssetService:CreateMeshPartAsync(
Content.fromObject(NewEditableMesh),
{ CollisionFidelity = Enum.CollisionFidelity.Box }
)
MeshPart.CFrame += Vector3.new((LENGTH * 1.5), HEIGHT / 2, 0)
MeshPart.Anchored = true
MeshPart.Parent = workspace
-- later on, player does interaction, need to adjust the created MeshPart
local function AdjustWallSegment()
local newPreviewMesh = AssetService:CreateMeshPartAsync(MeshPart.MeshContent)
local Face = "Front"
local OppositeFace = "Back"
local OffsetVec = Vector3.new(10, 0, 0)
local function AdjustVertex(vertexId, offset)
NewEditableMesh:SetPosition(vertexId, NewEditableMesh:GetPosition(vertexId) + offset)
end
-- Move one end of the chosen face
for i, vertexId in MeshFaces[Face].Vertices do
if i == 1 or i == 4 then
AdjustVertex(vertexId, OffsetVec)
if Face == "Front" then
if i == 1 then
AdjustVertex(MeshFaces.Top.Vertices[2], OffsetVec)
AdjustVertex(MeshFaces.Bottom.Vertices[1], OffsetVec)
end
else -- Back
if i == 4 then
AdjustVertex(MeshFaces.Top.Vertices[4], OffsetVec)
AdjustVertex(MeshFaces.Bottom.Vertices[3], OffsetVec)
end
end
end
end
-- Move opposite face’s matching vertices the opposite way
for i, vertexId in MeshFaces[OppositeFace].Vertices do
if i == 2 or i == 3 then
AdjustVertex(vertexId, -OffsetVec)
if OppositeFace == "Front" then
if i == 3 then
AdjustVertex(MeshFaces.Top.Vertices[3], -OffsetVec)
AdjustVertex(MeshFaces.Bottom.Vertices[4], -OffsetVec)
end
else -- Back
if i == 2 then
AdjustVertex(MeshFaces.Top.Vertices[1], -OffsetVec)
AdjustVertex(MeshFaces.Bottom.Vertices[2], -OffsetVec)
end
end
end
end
local RenderScale = MeshPart.Size / MeshPart.MeshSize
MeshPart:ApplyMesh(newPreviewMesh)
MeshPart.Size = RenderScale * MeshPart.MeshSize
print(RenderScale, MeshPart.MeshSize, newPreviewMesh.MeshSize)
end
task.wait(3)
AdjustWallSegment()
it doesn’t alter the collisions at all. the segment stays the same, regardless of faces being adjusted.