I am running into the fetch asset error wayy too frequently. I used to be able to load a bulk lot of images to EditableImage pretty well instantly, but now this low rate limit is heavily affecting my game.
And once this error has occurred, it is super slow trying to reload the assets.
This is really impractical for me
Mhm, same here - I’m slowed down a ton because I’m loading the same mesh multiple times and I have to make a fresh API request for each meshPart. In the past I’d just clone / copy it, however that isn’t enabled anymore to my understanding.
I’m getting an error when I try to convert a skinned mesh into an editable mesh
Failed to create mesh rbxassetid://71004912922216, Unable to convert mesh with skinning data
Am I doing something wrong or is there no support for skinned meshes?
Skinned meshes are not yet supported, although it’s something that we’re working on
Is EditableMesh:Clone going to get a replacement? Is there currently a new way to do this? I previously used it to reuse editable meshes that I don’t need to be re-generating everytime.
I’m struggling to transition to the new workflow as I’m finding a lot of fundamental features have been removed such as :Clone and :Destroy which breaks my code.
I have an issue where if I create a mesh part from an editable mesh, and then later use that same meshPart’s MeshContent variable to create a new editable mesh, it errors saying “Failed to load mesh”.
local AssetService = game:GetService("AssetService")
local eMesh = AssetService:CreateEditableMesh();
local v0 = eMesh:AddVertex(Vector3.new(0, 0, 0));
local v1 = eMesh:AddVertex(Vector3.new(1, 0, -1));
local v2 = eMesh:AddVertex(Vector3.new(1, 0, 1));
eMesh:AddTriangle(v0, v1, v2);
--Works fine
local firstMeshPart = eMesh:CreateMeshPartAsync(Vector3.one);
firstMeshPart.Parent = workspace;
--Errors with "Failed to load mesh"
local newEMesh = AssetService:CreateEditableMeshAsync(firstMeshPart.MeshContent);
Also another thing to note, using EditableMesh:CreateMeshPartAsync() is painfully slow to load as it only allows to create about 20 meshes a second which is far below what I need for my use case; what used to take 20 seconds now takes 200 seconds.
I did- but it seemed to insist I put the mesh on a MeshPart . Accepting this might be necessary, I tried to “Apply” that meshpart onto the other and it just told me it was empty, despite the original meshpart being fine. I’m not really sure why we need to make a new part, rather than simply apply the mesh onto an existing part. This is incredibly cumbersome and I hope not the only way.
Whelp, this screwed everything up for me. Got the system working as it was before and
a) Performance went off a cliff. What previously was smooth as butter now just chunk-chunk-chunks along.
b) Meshes no longer rendered if even a part of their extent was off the camera. So meshes were constantly popping in and out of view because the rest of the mesh WAS in the camera view.
Part B for you also happens for me, meshes will disappear if they go even a little bit off the screen or they get within a few studs of the camera.
Sorry, I should have been more specific.
IIRC EditableMeshes had a :Clear() method before and that was what I was referring to
So unfortunately due to the new permissions update this just completely destroys my plugin’s use-case. My plugin is used to check the triangle counts of meshes within the game using EditableMeshes however due to the permission update you are no longer able to do so unless you own the mesh itself. This is a huge issue especially with group places as for some reason even the owner of the group in the game I’m in can’t use the EditableMeshes as they don’t have permissions for the assets Even though they uploaded them.
I wish I had a reasonable solution but the only solution I could think of would only benefit myself, and that would be to add a :GetTriangles() method to MeshParts. This isn’t ideal perhaps plugins could be exempt from these permissions? Realistically anyone could export a mesh as an OBJ in studio so it’s possible to edit meshes without permissions anyways, so having an exemption for plugins wouldn’t be too far off.
I would really like this plugin to work again as it’s helped a lot of people including myself to find meshes that have way too many triangles in a game and I would really like to continue to use it.
It appears they broke support with decals. that way, in previous version, you can put decals to EditableImages, and they show that way. in this update, decals dosen’t have TextureContent, and decals just turned to uploaded images only, instead of editable one. Please add TextureContent to Decals, so we can use EditableImage to Decals.
We really don’t have any other way of doing this other than uploading 60 sprites to roblox and switching between them in real-time. It would be game-changing if roblox allowed for some sort of UV offset property on meshes, so hacky methods like using EditableMeshes became obsolete and we could make more performant effects.
I’m still recieving the same ‘Lacking Capability’ error from the function. Any help?
Exactly, my complement was to render the player’s map (including meshes with their textures or PBR’s) but, Roblox preferred to limit this only to what belongs to the player, when in the same way the player can export it and upload it to their inventory. This change does not make sense and it affects me in more than 4 things that I was creating. I really expected an improvement, and even though it was there, this doesn’t make up for it, I’m disappointed and upset.
Okay, so I understand why this policy is in place. However, I have some legitimate needs for analyzing meshes made by other users. In particular, analyzing potentially malicious UGC items and layered clothing assets on avatars in a competitive game.
I want to analyze layered clothing cages to see if they substantially warp the geometry of the avatar adorning them, so I can ban bad avatars from my shooter game and still allow non-malicious uses of layered clothing to pass.
Can anything be done to meet the needs of this use case?
Similarly with 2D clothing, it is impossible to emulate Roblox’s Humanoid texture compositor in Luau unless we can load shirts and pants. Frankly, if it is loaded into our game, we should be allowed read-only access to avatar assets in games.
I’m not fan about permissions, this model is not edited and is literally made by Roblox (?), but still, says me it’s not mine :
7430070993 is the MeshId of the head.
Some other infos
making a triangle where the Y position of all 3 vertices are the same seems to make the triangle invisible. Not sure if i’m doing something wrong or if this is a bug.
this works fine.
local positions = {
Vector3.new(10, 1, 10),
Vector3.new(0, 2, 10),
Vector3.new(10, 3, 0)
}
but changing the Y position to 0 for all 3 vertices makes the triangle invisible and even makes the SpawnLocation invisible
local positions = {
Vector3.new(10, 0, 10),
Vector3.new(0, 0, 10),
Vector3.new(10, 0, 0)
}
HighLight in the SpawnLocation makes it re-appear but the triangle won’t show. You also can’t see it in the wireframe view.
local AssetService = game:GetService("AssetService")
local editableMesh = AssetService:CreateEditableMesh({Size = Vector3.one})
local positions = {
Vector3.new(10, 0, 10),
Vector3.new(0, 0, 10),
Vector3.new(10, 0, 0)
}
for i = 1, 3 do
editableMesh:AddVertex(positions[i])
end
editableMesh:AddTriangle(table.unpack(editableMesh:GetVertices()))
local function computeExtents(em: EditableMesh)
local verts = em:GetVertices()
if #verts == 0 then
return Vector3.zero
end
local inf = math.huge
local min = Vector3.new(inf, inf, inf)
local max = Vector3.new(-inf, -inf, -inf)
for _, id in verts do
local v = em:GetPosition(id)
min = min:Min(v)
max = max:Max(v)
end
return max - min
end
local meshPart = editableMesh:CreateMeshPartAsync(computeExtents(editableMesh))
meshPart.Anchored = true
meshPart.Position = Vector3.new(10, 10, 10)
meshPart.Parent = workspace
TriangleIssue.rbxl (53.3 KB)
So if we have an NPC with roblox’s default animations how are we going to get the ids of it? also that might break a lot of games. But i like that because we wont have to call api every time which causes a lot of loading errors.