AssetService:CreateMeshPartAsync() Does not support DoubleSided.
DoubleSided Property in Meshpart is locked behind PluginSecurity.
That means, you still need to copy Meshpart with DoubleSided Property, as there’s no way to turn on DoubleSided property with server scripts.
i seem to have found 2 more bugs 1 being that making an editablemesh is taking 16ms no matter what
this happens for every editablemesh i make and changes my terrain generation from taking 3ms every frame to 16ms.
The other bug is when you stop playtesting on the same frame an editablemesh is made your studio crashes.
normal behaviour that doesn't crash because all meshes are constructed
crashes when i stop playtesting while an editablemesh is loading / being made the same frame
Just wanted to ping this post and point out that the developer hub entry for EditableImage is completely wrong, saying you need to use Instance.new() to create them and using the old paradigm.
2 Likes
Thanks for pointing this out, I will update this documentation.
2 Likes
Will there ever be support for editableimage on textures and will :crop() comeback?
We will be adding support for EditableImage on Textures. We don’t currently plan on directly bringing Crop back, but we will be introducing a new DrawImageTransformed API in the next release, which should cover this use case along with Resize and Rotate.
1 Like
What is “Write Marshalled” caused by and why does it take so long?
It is causing it to take 4 seconds to generate a 10k triangle mesh instead of the ~33ms that it takes to add triangles & create the mesh.
I’m having trouble rendering an EditableMesh in Studio inside a ViewportFrame parented to StarterGui. This is what I’m getting:
I’ve tried multiple things, but I kept getting the square.
My intended purpose is to use EditableMesh for in-studio plugin overlays.
1 Like
Hi! Do you have a placefile you could share with us? We’d love to take a look. Feel free to submit a bug report or share it privately. Thanks!
Absolutely. I made a smaller example here. It still has the same issue
EditableMeshCrashing.rbxl (53.6 KB)
1 Like
nice. and will there be a way in the future to make decals and textures pixelated like the imagelabels resamplemode?
You could probably do that yourself.
If you put low res images in decals it is all blurry
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
7 Likes
Thank you so much for this
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.
2 Likes
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 
1 Like
Ridiculous how this is necessary for it to work and how the staff isn’t addressing this dumb issue, you’re a life saver.
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.
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.
1 Like