[Client Beta] In-experience Mesh & Image APIs now available in published experiences

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.

9 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???)

14 Likes

Are there any plans to add a method to editable meshes to change the fixed size property for cases where someone would create a mesh, add geometry, and then make it fixed sized after the fact to reduce memory in the long run? This would be very useful for terrain and foliage creation.

I’ve attempted to make a duplicate editable* (with a fixed size) using assetservice with a content object created from the editable*; however, I encountered a bug I remarked in a previous forum post from the studio beta where content objects do not load into editables or meshes when the content object originates from another editable*.

keep up the good work and updates, love the potential being offered here

This was done to help save memory. Each EditableImage and mesh requires memory, and this change made it usable like regular IDs. Imagine having giant map with similar trees, but each of them consuming like 2500% more memory than needed? Same for other repeated props, like stones.

I’m really curious behind the implementation of this!

Are you using an editable image for the diffuse of the ocean? It looks kind of like a noise texture multiplied by a color. What about the normal maps? Are those purely static? This looks really impressive and I’d love to know more about this! :o

not even letting us use this feature by ourselves in an unpublished place without ID verification is wild

4 Likes

I have a question, I’m loading images from AI Generators like Dall-E (which itself is moderated), and I’m also planning to put it through another moderation model for images would that be fine to use. Not to mention I will also be filtering the prompt for images to make it harder to generate anything innapropriate.

>Manage memory using FixedSize
>Can only set FixedSized upon mesh creation, so it can only ever be empty

Thanks Roblox

2 Likes

I was even hoping that one would be able to use this on publicly available meshes. Would there eventually be an update to deal with stuff like that?

That is good to hear! Thank you for the information. Good luck.

My entire project has now been rendered redundant because of this stupid permission change, we are on the same boat.
I also think your suggestions are really solid; Disabling asset publishing for sampled assets sounds like something roblox’s PR could get behind (maybe, i mean it is roblox after all)

but yeah, R.I.P. pixel world :headstone: :rose:

9 Likes

Hey, I’m the Image Editor plugin guy

I remember addressing the issue with the permissions change and I’ve been told my use case would be considered. Is there any chance we can see that happening next update? ( [Studio Beta] Major updates to in-experience Mesh & Image APIs - #109 by FGmm_r2 )

If the permission check to turn images into EditableImages could be lifted even if only in studio it would make the plugin I’m working on way more powerful while causing no harm I believe


^ Now that :DrawImageTransformed is added I could fix the whole plugin, I only need the studio publishing feature to release :partying_face:

9 Likes

Yes, there are plans to allow that, but didn’t make it in time for the initial release. There are plans to be able to ‘bake’ an EditableMesh into one that doesn’t affect the budget, and to have a maximum budget instead of fixed or 20,000 faces.

5 Likes

We’re looking into ways to open this up in the future. We know it’s annoying, it’s a requirement we added reluctantly, and we want to make this less restrictive longer-term.

These APIs are still a huge bump in creative power. The performance at a given fidelity is definitely higher. If you don’t care about framerate at all or if you squint hard enough it is technically equivalent, but it definitely makes creating content at runtime easier and more efficient. That’s the whole point!

For now, it is hopefully a more minor hurdle for a well-meaning developer like yourself than it would be for someone intent on using these APIs to create egregiously policy violating content.

11 Likes

Any ETA for skinned or testing with it? Maybe Early or Mid-2025?

1 Like

It’s not a minor hurdle. Giving away super personal information isn’t a minor hurdle. It’s less like a small detour, and more like trying to drive around a supermassive blackhole. You aren’t deterring bad actors with this, you’re deterring good actors. Bad actors will find a way around this limitation, just like they did for everything else.

Imagine coming over from a different engine and being told, “This feature you had? Sorry bud, you’ll have to cough up your ID. Don’t want bad things to be made! Oh, you don’t feel safe giving up information that is THAT personal? Bugger off then, come back when you’ve lost the common sense.”

8 Likes

its more-so that the malicious people create a freemodel that creates horrible things, and then little timmy unknowingly adds it to his game