Thanks a lot for that. I’ll get a fix for this soon.
1 Like
We changed UGCValidation to use the Editable* APIs internally in preparation for some future work. Let me look into this and potentially disable this change.
1 Like
I’m really glad that this feature is near release! 
But just for clarification, Skinned Editable-meshes will work with animations like how normal skinned meshes do correct?
I’m experimenting with generating voxel meshes using EditableMeshes, but I’ve encountered significant performance issues when using Precise Convex Decomposition for collision fidelity:
- Rendering only the outer faces of a voxel mesh up to a size of 14×14×5 takes 5–8 seconds to instantiate a MeshPart.
- However, increasing the size to 15×15×5 causes the instantiation time to skyrocket to nearly a full minute!
This is very surprising, as the mesh I’m instantiating is very simple (as you can see in the video below).
Here’s the code I’m using to measure instantiation time:
local t = os.clock()
worldMeshPart = AssetService:CreateMeshPartAsync(Content.fromObject(eMesh), {CollisionFidelity = Enum.CollisionFidelity.PreciseConvexDecomposition})
print(os.clock()-t)
Also, when enabling Render Collision Fidelity in Roblox Studio’s viewport settings, the collision decomposition for the EditableMesh doesn’t appear to display at all. This occurs regardless of the collision fidelity setting (PreciseConvex, Default, Hull, andBox).
Here you can see a video of the 15×15×5 mesh with precise convex decomposition, and a demonstration of the collision fidelity display not working. The debug output shown in the video also shows the output of the code snippet provided above.
Is this performance behavior expected for Precise Convex Decomposition? I’ve tested other, more complex meshes from the toolbox with collision fidelity changes to Precise Convex Decomposition, and they took less than 1 second to convert in Studio.
Are there any known fixes for EditableMeshes that could address this? Is this extreme delay a bug?
Is there any way to make the Render Collision Fidelity setting display the decomposition for this EditableMesh?
3 Likes
The 13+ ID verification requirement to use the API only applies to the owner / group owner of the experience, not to individual users in the experience.
The 13+ age requirement for freeform creation is a separate content guidelines / age recommendations policy. That one doesn’t depend on which technology you use, just the experience that you build with it. It applies to rotated Frame-based drawing tools as well as EditableImage.
If you are using Editable* for procedural generation that is not freeform user-driven creation, only you, the developer, would need to be ID verified. Usage of Editable* does not automatically make your experience 13+ only.
3 Likes
Why though? I have pointed out already that this efforts are completely useless, as developers on roblox can already make enough with existing features, but with degraded performance… (look my message somewhere above)
Maybe I missed something important that you guys know about that?
3 Likes
It seems that every editableMesh/Image update that gets released, the worse it gets. When editable meshes and images had first released, they were really easy to use, and yeah, the new Api features that have been added are cool and useful, but it seems like the process has been extremely overcomplicated now. I used to be making tons of stuff with editable meshes and images but now I can’t even figure out how to get a live render of a plane.
and all of these “security features” are just stupid. how is preventing the use of other people’s meshes going to stop anything?? it’s not. if someone wanted to do something bad with meshes, chances are they’re going to any of the thousands of sites or apps to get or make models. and the same thing can be said towards images.
and the fact that you guys are going to lock an Api behind 13+ and ID verified because your moderation sucks is beyond sad.
leave it to roblox to ruin what could’ve been the best update to release.
13 Likes
How to use it via script? ‘EditableMesh’ instance was removed. How to do this now?
Could someone explain how say I can make a cube using EditableMesh? I’m so confused with the API rn
Could we at least get an API to read the dimensions of an image asset? This was honestly half the reason I was excited for EditableImage.
1 Like
Pretty upsetting that we can only use images/meshes that we own, especially when ROBLOX avatars are completely complied of other peoples assets. I had been working on a feature that involves roblox avatar textures that I cannot use anymore
3 Likes
Please add back EditableMesh:Clone()! It previously had a huge benefit since I’m making multiple of the same meshes editable. With some recent changes it doesn’t look like this is possible anymore (if I’m wrong please let me know).
My code consists of a lot of
...
EditableMesh = AssetService:CreateEditableMeshAsync(MeshPart.MeshContent)
...
local newMeshPart = AssetService:CreateMeshPartAsync(
Content.fromObject(EditableMesh)
)
MeshPart:ApplyMesh(newMeshPart)
That has unnecessary load time. It’d be nice to be able to generate the MeshPart once, cache it, and somehow be able to clone it along with its EditableMesh that it was created from.
4 Likes
Hello! Since unfixed EditableMesh can currently allocate and deallocate vertices and triangles, we can’t predict the exact memory usage. We’re currently taking a conservative approach and assuming the worst-case scenario based on the potential size of an editable mesh. In the future, we plan to provide options for creators to define the max number of triangles an unfixed EM may use, allowing for better memory estimation and management. In the meantime, you can merge multiple EMs into a single larger one and use Destroy() on the previous EMs to reclaim memory. Alternatively, you can use createEditableMeshAsync with FixedSize = false . We are iterating on the memory budget system to make it more dynamic.
1 Like
That’s actually kinda works to be honest. Thanks for the additional clarification.
Though i still have to ask, why lock this feature behind 13+ ID verification for developers to use (outside of freeform creation of course)? Developers with or without Editable images/meshes would still be able to generate inappropriate content. The new Editable images/meshes won’t change anything about that fact so what gives?
4 Likes
Currently EditableMesh skinning support is unfinished, and not yet enabled. But when it is done, that’s the plan.
It’s certainly not what I expected! Thanks for the report, we will look into it.
Sure, here’s a small sample that makes an EditableMesh cube and adds it to workspace so you can see it.
Code sample to make an EditableMesh cube
-- LocalScript
local AssetService = game:GetService("AssetService")
-- Given 4 vertex ids, adds a new normal and 2 triangles, making a sharp quad
local function addSharpQuad(emesh, vid0, vid1, vid2, vid3)
-- AddTriangle creates a merged normal per vertex by default.
-- For the sharp cube, we override the default normals with
-- 6 normals - a new normal to use for each side of the cube
local nid = emesh:AddNormal()
local fid1 = emesh:AddTriangle(vid0, vid1, vid2)
emesh:SetFaceNormals(fid1, {nid, nid, nid})
local fid2 = emesh:AddTriangle(vid0, vid2, vid3)
emesh:SetFaceNormals(fid2, {nid, nid, nid})
end
-- Makes a cube with creased edges between the sides by using normal ids
local function makeSharpCube_splitNormals()
local emesh = AssetService:CreateEditableMesh() -- creates an empty EditableMesh of unbounded size
local v1 = emesh:AddVertex(Vector3.new(0, 0, 0))
local v2 = emesh:AddVertex(Vector3.new(1, 0, 0))
local v3 = emesh:AddVertex(Vector3.new(0, 1, 0))
local v4 = emesh:AddVertex(Vector3.new(1, 1, 0))
local v5 = emesh:AddVertex(Vector3.new(0, 0, 1))
local v6 = emesh:AddVertex(Vector3.new(1, 0, 1))
local v7 = emesh:AddVertex(Vector3.new(0, 1, 1))
local v8 = emesh:AddVertex(Vector3.new(1, 1, 1))
addSharpQuad(emesh, v5, v6, v8, v7) -- front
addSharpQuad(emesh, v1, v3, v4, v2) -- back
addSharpQuad(emesh, v1, v5, v7, v3) -- left
addSharpQuad(emesh, v2, v4, v8, v6) -- right
addSharpQuad(emesh, v1, v2, v6, v5) -- bottom
addSharpQuad(emesh, v3, v7, v8, v4) -- top
-- Because we override all of the default normals, we can remove them
emesh:RemoveUnused()
return emesh
end
-- Create the cube and preview MeshPart
local emesh = makeSharpCube_splitNormals()
local previewMesh = AssetService:CreateMeshPartAsync(Content.fromObject(emesh))
previewMesh.Anchored = true
previewMesh.Position = Vector3.new(0, 5, 0)
previewMesh.Size = Vector3.new(5,5,5)
-- Add the preview MeshPart to workspace
previewMesh.Parent = workspace
3 Likes
off topic, but will you guys ever consider allowing particle emitters to have the shape of the parented part itself? i.e if I have a donut, the particle emitter will emit to form a donut?
Couldn’t have resonated with me better. I have really strong feelings about the fact they changed the structural foundational hierarchy just to include Content, only for what? to render the same thing on different meshes?
It was as easy as inserting EditableMesh and get right to the fun stuff. Sure, that’s too easy. We can’t have that. Let’s make it harder and laggier to initiate them, place arbitrary ‘trust us’ memory guard rails with an vague promise of “We’ll improve and expand it soon!” with no roadmaps or certainty…It was already perfect, It didn’t need to change, It needed to be this way. but no, It was our fault for trying I guess.
Out of the few cool experiments and prototypes I developed with my spare time, none of them work anymore. And probably will never get back to because of the possibility it will never see the light of day due because ToS bureaucracies from within wall-guarding my game. What’s even the point in making anything cool when the same company antagonizes us for trying?
Has there ever been a time where we were working together rather than working against eachother? It’s not even an secret anymore that devs would use alt accounts to upload assets because they are afraid of false termination. There is a growing level mistrust between us and ultimately Roblox neglected the fact we just want to make games.
I give up with working with Editables*. To whoever gets a full game working with all of these limitations you have my utmost respect in every regard.
10 Likes
Better start writing that email to roblox about restricting “BasePart” to id verified users, then.
3 Likes
Roblox keeps saying the permission checks are in place to “prevent misuse”. They always use this exact wording. I’m really curious, what “misuse” are they worried about?
It’s so frustrating how Roblox waves this game-changing API in my face that I can’t do anything with anymore, and only gives a vague reason of “preventing misuse”, which could really mean anything. These strict permission checks kill off most of my use cases.
This “misuse” they talk about can’t mean inappropriate TOS-violating content, right? Surely the ID verification requirement is enough to discourage that, and besides, it’s not like anything inappropriate that can be made with Editable* objects can’t already be accomplished with basic parts.
Maybe, since Roblox wants to make it so that you can publish meshes and images in-experience through AssetService:PromptCreateAssetAsync(), they want to ensure you can’t just steal someone’s mesh/image by turning it into an Editable* object and re-publishing it like so. That would make sense. I can’t think of any way of preventing that.
If that’s the case, then, since these APIs already require you to manually enable them in Game Settings before you can use them, what about introducing a separate toggle in Game Settings that enables Editable* objects to bypass these permission checks, but also completely disables the publishing of Editable* objects with PromptCreateAssetAsync? I don’t know if this would be the best solution but I’m sure most devs who want to load un-owned assets into an Editable* object really don’t care about users being able to publish them or not.
I used to think these APIs would be the future of Roblox, but I personally just don’t have that much use for them anymore. I really hope Roblox can figure out a solution to this because this is just so disappointing after all the hype from when these APIs were being developed.
(Also, ID verification for an engine API? I’m already verified so I don’t really care, but, really???)
15 Likes