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

Updates Announcements
,
#102

Thanks a lot for that. I’ll get a fix for this soon.

#103

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.

#104

I’m really glad that this feature is near release! :happy1: But just for clarification, Skinned Editable-meshes will work with animations like how normal skinned meshes do correct?

#105

image
image773×475 35.2 KB

13 Likes
#106

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?

2 Likes
#107

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.

1 Like
#108

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?

1 Like
#109

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.

7 Likes
#110

How to use it via script? ‘EditableMesh’ instance was removed. How to do this now?

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

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

3 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.

8 Likes
#122

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

1 Like