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
1 Like
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.
1 Like
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?
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
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!
1 Like
Can you provide a place file that reproduces this issue?
EditableImage seems to be working in my tests, so your setup might be different.
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!
It worked, thank you! I strongly suggest you update the documentation for WritePixelsBuffer, it was a bit misleading, as it was missing the alpha.
1 Like
Thanks for pointing this out; I’ll improve the documentation for WritePixelsBuffer to make it clearer.
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) .
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.
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.
1 Like
We’re removing the MeshSize override for now because it allowed creating parts with physical geometry larger than 2048x2048x2048 by specifying a MeshSize far below the actual extents of the mesh. A lot of people did it accidentally by passing Vector3.one instead of a size from the mesh or an existing MeshPart.
You’ll have to update the Size of the part when replacing the MeshContent on an existing part with ApplyMesh().
When applying updated geometry to a MeshPart using the same mesh you probably want to keep scale constant, so considering…
renderedMeshScale = meshPart.Size / meshPart.MeshSize
You’d do something like…
local newPart = AssetService:CreateMeshPartAsync(Content.fromObject(em), ...)
meshPart.Size = newPart.MeshSize * (meshPart.Size / meshPart.MeshSize)
meshPart:ApplyMesh(newPart)
Consider caching the scale factor (in parenthesis) if you’re updating frequently over long periods of time. If you’re doing this iteratively over time it can accumulate a small amount of error and that scale factor might drift slightly over long periods of time if recalculated from size each time.
1 Like
run a for loop in a smaller res than the image, scale these iterations proportionately along the image, get the color data for those pixels, and make a new image that draws clusters of pixels that represent each downscaled pixel
problem solved
1 Like
this is because all vertices’ Y positions are the same. It’s been a bug for a bit now.
You can fix it by making sure they’re not all on the same Y position like this
local v1 = eMesh:AddVertex(Vector3.new(-5, 0, -5))
local v2 = eMesh:AddVertex(Vector3.new(5, 1, -5)) --> change it to something that's not also 0
local v3 = eMesh:AddVertex(Vector3.new(-5, 0, 5))
local v4 = eMesh:AddVertex(Vector3.new(5, 0, 5))
3 Likes
Thanks for sharing! Both are fixed and will be updated soon!
1 Like
I’m enabling a change to log a warning each time EditableMesh:CreateMeshPartAsync is called:
EditableMesh:CreateMeshPartAsync is deprecated and will be removed in the next release. Use AssetService:CreateMeshPartAsync instead.
Planning to disable EditableMesh:CreateMeshPartAsync a week from now, next Wednesday.
My studio client is crashing when pressing the stop button during a play solo test when using EditableImage.
Here’s a repro place:
bugTest.rbxl (55.5 KB)
Log file:
0.650.0.6500743_20241107T083141Z_Studio_EFD72_last.log (502.6 KB)
Simply just run a solo test, maybe walk around for a couple seconds, and then press stop, and it will freeze the client for a few seconds and then close the window.
2 Likes