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

Updates Announcements
,
#111

Could someone explain how say I can make a cube using EditableMesh? I’m so confused with the API rn

#112

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.

#113

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

#114

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.

#116

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
#117

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?

#118

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

1 Like
#119

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?

#120

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.

5 Likes
#121

I’m seriously considering switching to unity/godot/unreal atp

Here’s some advice if you’re considering Godot:

If you want to make 2D games, with a slightly outdated 3D engine, and you want to export your games to the web, use Godot 3.

The latest version of Godot 3 (3.6) has a feature complete 2D engine, pretty much every feature you need to make 2D games is available on Godot 3. There’s also an official, comprehensive tutorial that teaches you how to start making 2D games, vise versa for 3D.

Here is some things you are able to do the following with Godot 3 & 4 with the 2D engine:

The 3D engine in Godot 3 is fine if you’re not making sophisticated scenes, though you’d miss out on more advanced features that’ll be covered in the next section.

Here is some things you are able to do with Godot 3’s 3D engine:

If you want to make visually good 3D games, but is willing to sacrifice web exports (for now, at least), use Godot 4.

Godot 4 is primary focused on improving the 3D engine, it’s a complete overhaul, and improved upon Godot 3’s previous 3D features.

Here is some things you are able to do with Godot 4’s 3D engine:

Godot can also be used to make general purpose software, but be warned, users that relies accessibility tools like screen readers will not work.

What I like about Godot is how it’s designed to give you as much freedom as possible, because nothing is abstracted away by an algorithm, you rightfully fine tune how your game feels & looks like.

If something is not in the engine, what’s stopping you from adding it in? You can create plugins and publish it on the Asset Store, or suggest in the Godot github.

You are also able to use any language of your choice with GDNative (Godot 3) or GDExtension (Godot 4).

I recommend you try Godot. I’ve been using Godot for about a month at this point, and is definitely a breath of fresh air from Roblox.

10 Likes
#122

Better start writing that email to roblox about restricting “BasePart” to id verified users, then.

1 Like
#123

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.

image
image727×117 8.74 KB

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

4 Likes
#124

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

#125

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.

#126

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

#127

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

#128

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.

#129

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

Thanks Roblox

#130

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?

#131

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