[Studio Beta] Major updates to in-experience Mesh & Image APIs

[EgoMoose]

In case anyone else needs it. I wrote an equivalent for the old crop method from EditableImages:

local AssetService = game:GetService("AssetService")

local function crop(editImage: EditableImage, min: Vector2, max: Vector2)
	local sourceSize = editImage.Size
	local sourceBuffer = editImage:ReadPixelsBuffer(Vector2.zero, sourceSize)

	local targetSize = max - min
	local clampedWidth = math.min(min.X + targetSize.X, sourceSize.X) - min.X
	local clampedHeight = math.min(min.Y + targetSize.Y, sourceSize.Y) - min.Y
	local clampedSize = Vector2.new(clampedWidth, clampedHeight)
	local targetBuffer = buffer.create(clampedWidth * clampedHeight * 4)

	for y = 1, clampedHeight do
		local sourceOffset = min.X + (min.Y + y - 1) * sourceSize.X
		local targetOffset = (y - 1) * clampedWidth
		buffer.copy(targetBuffer, targetOffset * 4, sourceBuffer, sourceOffset * 4, clampedWidth * 4)
	end

	local output = AssetService:CreateEditableImage({
		Size = clampedSize,
	}) :: EditableImage

	output:WritePixelsBuffer(Vector2.zero, clampedSize, targetBuffer)

	return output
end

[greplol (ChillthriIl)]

Thank you so much for this ‎ ‎ ‎ ‎

[goodbadred (KIingac)]

Shadows seem to be messed up. If a part is big enough, the shadow is both on an EditableMesh and on a part under it, if it’s not big enough, the shadow doesn’t appear on a mesh at all.

[PysephDEV (Pyseph)]

bump – I had actually ran into the same issue while trying to edit your 1-mesh with bones character to have the same UV mapping as a normal R6 Roblox character – Blender was giving me a fight, so I figured I could just use EditableMeshes to get the job done. But unfortunately I don’t have permission to convert the mesh into an EditableMesh, as I do not own it, despite the place its from being open-source

[Itsyarne]

Ridiculous how this is necessary for it to work and how the staff isn’t addressing this dumb issue, you’re a life saver.

[ContextLost]

Size Limitations

Creating parts larger than 2048x2048x2048 definitely won’t be supported yet for the same reasons we don’t support this today. We’ve also been considering clamping the rendered size of an EM to that same limit. Would strongly recommend breaking things up into chunks.

Note that our terrain engine, even with a lot of internal specialization in rendering and physics, does break up the meshes per-chunk. Would strongly recommend doing something similar.

We’d like to support massive parts eventually but there’s a lot of work necessary to support this properly on both the rendering and physics engine side.

Empty Mesh Parts

On empty meshes we’re still debating what to do with this. I know it is a nuisance. We knew it would be. We knew in the design phases, we knew during the internal game jams.

We’re here gathering use cases and listening to feedback, but wanted to share some background.

Remember Roblox’s engine API is append only. Removing APIs or adding new limitations is basically impossible, so we have to move in careful iterative steps. Removing restrictions is easy, adding them later is insanely painful for everyone.

We’re not happy about this limitation either, but it’s where we’re starting today.

We have this limitation because, for better or worse, there’s intentionally no concept of guaranteed static geometry in our engine. Even without mesh-based collision geometry we have to generate mass and inertia properties for the part. Just in case it’s unanchored or you want to slice a piece off.

At least for a single triangle or an open mesh you’ll get some rational, mostly predictable results. For an empty mesh you’d get min clamped, infinitesimally small mass and inertia and extraordinarily poor behavior for any physical interaction.

If you know what “mass ratio issues” are, that, in the most extreme, for a would-be common-case usage.

We’re also transitioning to mass/inertia data generated from the mesh, regardless of your choice of collision fidelity. Previously/currently it was from the collision geometry. Box is maximally massive, but the other options have extremely variable behavior between the fidelity options, especially because Default/Precise tend to have many overlapping convexes and/or inconsistently hollow interiors. Considering that geometry based mass properties will be the one option in the future.

We’re ok with letting you do things that hit the mass/inertia clamps where that would be expected, but it seems like common case usage here would lead to people gradually building up a reasonably sized mesh that still has zero mass/inertia, and weird and unpredictable things happen when you touch it. I would not expect diagnosing why to be easy for all but the most advanced devs either…

Behavior would be innocuous when welded to another object, but if it was used a a single part assembly it’s going to explode the second it collides with or is constrained to another part.

I was having conversations about how weird it will be that you can generate a mesh from a triangle, create a part, remove that triangle, and the engine would be cool with it. It only works for EditableMesh because it’s a temporary visual/physical decoupling, which is otherwise something we try to avoid as a foundational design principle for the engine. It’s an area where that “digital matter” abstraction leaks a bit.

Listening to feedback. Hopefully you can sympathize that as a general case issue there’s some non-obvious complexity.

[ContextLost]

We just rolled out a change that should fix the CreateMeshPartAsync issue.

Known issue, fix was merged before the main-thread-blocking version shipped, but rolling out this internal method rewrite took longer than expected.

Sorry about that.

[pyxfluff (Pyx)]

I am still waiting on a Resize and Rotate replacement… when will these be coming? Stripping these features and giving silence to its users is ridiculous

[TheGamer101]

A Resize and Rotate replacement will be in the next release (the studio version is coming out this Wednesday if all goes well). I’m sorry for the inconvenience caused and the delay in re-enabling this functionality.

[iPeeDev (yosoyelfainaiatfredi)]

I understand is impossible to increase the size limits for this new mesh APIs, But are we gonna be able to use the SpecialMesh instance with editable meshes?

[CFoxy24 (CFoxy)]

Hello! This api is amazing, i’ve been experimenting with it since the beta release and it’s capabilities are mind blowing!
I am currently working on making a highly detailed sphere splitted into multiple meshparts. But im running into an issue with the culling of meshparts, it seems like the extent of the mesh is not updated when making an editable mesh from the ground up, i’ve tried everything that I could to solve the problem but I can’t found anything that can help, changing the CollisionFidelity to Box improve the culling but it is still visible, im posting here to know if i am making something wrong or if it is a bug. Thank you

[exyiel (ood)]

Hello. I believe EditableImages are currently broken. The image is not showing up whatsoever, even when using the example code from the documentation. I am doing ImageContent = Content.fromObject(image). please help!

[TheGamer101]

Can you provide a place file that reproduces this issue?

EditableImage seems to be working in my tests, so your setup might be different.

[exyiel (ood)]

So sorry for not providing a file in the original message:
editableimages.rbxl (56.2 KB)

[TheGamer101]

Looks like you just need to set the alpha value for the pixels you are adding to the buffer to get this to work.

		buffer.writeu8(pixels, pixelIndex, math.random(0, 255))
		buffer.writeu8(pixels, pixelIndex + 1, math.random(0, 255))
		buffer.writeu8(pixels, pixelIndex + 2, math.random(0, 255))

Should be:

		buffer.writeu8(pixels, pixelIndex, math.random(0, 255))
		buffer.writeu8(pixels, pixelIndex + 1, math.random(0, 255))
		buffer.writeu8(pixels, pixelIndex + 2, math.random(0, 255))
		buffer.writeu8(pixels, pixelIndex + 3, 255)

Let me know if this still doesn’t work!

[exyiel (ood)]

It worked, thank you! I strongly suggest you update the documentation for WritePixelsBuffer, it was a bit misleading, as it was missing the alpha.

[TheGamer101]

Thanks for pointing this out; I’ll improve the documentation for WritePixelsBuffer to make it clearer.

[Sqarv]

I dont like the permissions . I made a wireframe rendering system using editable meshes to get the data of a mesh to render it but isnt working anymore . (i want to use this for a game where players can build and use different meshes) .

[Haggie125]

Is there a way to pass a mesh size to CreateMeshPartAsync? Sending it as the first argument doesn’t seem to work now and I don’t see a way with the options table.

[yyyyyy09 (crushmero)]

Will we see permissions be fixed at the very least for groups:

I own this asset yet because I’m in a group game I’m unable to view it as an editable mesh

We have about 3102 meshes that have this issue due to uploading to Me rather than the group

Also will plugins be able to bypass these permissions? Exporting as an Obj is still a viable option for editing meshes from studio without running into permission issues.