This new API change is really confusing me and I’m having trouble getting my editable mesh to render onto a mesh part. Previously, when the editable meshes were instances, I would just delete the EditableMesh instance, create a new one, and re-parent it to the MeshPart every time I updated it. I’m having trouble even figuring out how to get this to work now, as the MeshPart just becomes completely invisible with no errors in the output.
This is what I have right now:
self.MeshPart = game.ReplicatedStorage.MeshPart:Clone()
self.MeshPart.Name = "Primary"
self.MeshPart.Size = size
self.MeshPart.Position = self.Origin
self.MeshPart.Anchored = true
self.MeshPart.CanCollide = false
self.MeshPart.CanTouch = false
self.MeshPart.CanQuery = false
self.MeshPart.Transparency = 0.75
Instance.new("SurfaceAppearance", self.MeshPart)
self.MeshPart.Color = Color3.fromRGB(33, 84, 185)
self.MeshPart.Parent = self.RadiusPartsModel
function Update()
Calculate() -- Creates and adds an EditableMesh filled with triangles called self.Mesh
local referenceMeshPart = AssetService:CreateMeshPartAsync(Content.fromObject(self.Mesh))
self.MeshPart:ApplyMesh(referenceMeshPart)
end
When I run the game, nothing gets rendered. This worked before the change in the API and I’ve been trying to get this to work for days with no avail. Can someone please help me out?
This seems like it should work. Is self.Mesh a perfect plane? We’re currently working on a bug where a perfect plane doesn’t convert / render successfully with the API changes.
@TheGamer101 Hey, would like to report a bug that’s been affecting workflow and limiting us.
Sometimes, creating 2 or more EditableImages will sometimes cause one not to render. I doubt this is a memory limit issue as I have 32gb of memory. it even happens on small EditableImage sizes (such as 52x52)
Notice how the ImageLabel layer with the cursor re-appears after I remove the EditableImage from a different ImageLabel
I’m currently working on a fix to that issue, but as a temporary workaround, you can offset one of the vertices of your mesh by a small amount, like 0.001.
The problem is that when we’re converting from an EditableMesh to a MeshPart, we compute physics information, which doesn’t work well when the mesh has zero volume.
I got my code working again thanks to the workaround provided, however I’m noticing two issues. For reference I’m using two EditableMeshes to create a line of sight system. Let me know if you would like me to send you the place file.
The MeshPart blinks each time I update it. Before, when the system used Instances instead of Objects, it did not do this and rendered immediately when the EditableMesh was parented to the MeshPart. Since the change, the mesh glitches out when updated at a high rate. Lowering the update frequency does not fix this as the blink is still visible. Watch 2024-11-19 18-30-06 | Streamable
The MeshPart is centered and all vertices are based off of the size and position of the MeshPart, however the triangles are offset. Focus on the red mesh, before the update it would always be 100% aligned with the blue mesh but now it’s not. It’s easier to see what I mean when I create triangles on opposite sides of the circle. All of the vertices created from the yellow parts never move and are always in the same position, but they get offset by new triangles being created. Watch 2024-11-19 18-28-29 | Streamable
Switching from Wedges to an EditableMesh has increased performance for my line of sight system substantially, I’m excited for when this officially gets released. One request I have is a way to reset all of the vertices and triangles in an EditableMesh back to an empty mesh. What I have to do right now is create a new EditableMesh and apply it to the MeshPart each time the Update function is called, however it would be nice to be able to just clear and rewrite to the same EditableMesh since it will automatically update and eliminates the need to create new Objects.
the memory limits changed and now i can barely make more than 5 editable meshes, is there anything i can do? (they’re like 120 studs big and only have 72 tris so i dont know why im reaching the limit so easily)
also occlusion culling isn’t working right when there’s other objects on top it but the bounding boxes look fine i think. im not changing the position or size of the meshpart after calling CreateMeshPartAsync or using a pre-existing mesh like a plane
Bumping this question as the issue hasn’t been solved or been replied to.
Would it be possible to allow Editable api to access assets uploaded by a user that has studio access in a group.
For anyone struggling with procedurally generated EditableMeshes which may or may not be perfectly flat (In my case, for voxel-based meshes), I’ve written a helper function to automate the workaround for the zero-volume physics bug.
The function uses EditableMesh:GetSize() function, which I believe is equivalent to the computeExtents function referenced in the original post:
It works by checking if any axis has zero size. If so, it offsets a vertex by 0.001 studs along that axis to ensure the mesh has non-zero volume.
Feel free to use it in your projects!
-- Ensures the EditableMesh has non-zero extents by slightly offsetting a vertex if needed.
-- This workaround addresses cases where perfectly flat meshes (zero extents along an axis)
-- fail due to physics computation issues.
--
-- Returns:
-- boolean (success) - True if adjustments were made, False if no adjustments were possible.
local function ensureMeshVolume(eMesh: EditableMesh): boolean
local vertIds = eMesh:GetVertices()
local vertId = vertIds[2] -- Select the second vertex (if it exists)
if not vertId then return false end -- Give up if there are less than two vertices.
local offsets = {
Vector3.xAxis,
Vector3.yAxis,
Vector3.zAxis
}
local extents = eMesh:GetSize()
-- Check each axis for zero size
for i, axis in ipairs({"X", "Y", "Z"}) do
if extents[axis] == 0 then
-- Add a small offset along this axis to create volume
local position = eMesh:GetPosition(vertId)
local delta = offsets[i]*0.001
eMesh:SetPosition(vertId, position+delta)
end
end
return true
end
Note: From my testing, this glitch doesn’t occur for all meshes with zero volume. It specifically affects meshes with an axis-aligned bounding box that has zero volume. For example, a perfectly flat plane rotated such that its bounding box has non-zero size along all axes does not seem to cause issues. As a result, this function only modifies the mesh based on its extents size.
I’m having the same problem, and Roblox seems to cull the mesh whenever this (incorrect) bounding box is offscreen. Does anyone have a workaround for this?
Edit: It seems like the bounding box is always offset by a value equal to EditableMesh:GetCenter().
For example, if an editable mesh has one corner at the origin (in local coordinates), the bounding box will be centered at the opposite corner instead of the actual center of the mesh.
In the example above, my mesh has one corner near the origin, and you can see that the bounding box is indeed centered within a few studs of the opposite corner of the whole mesh.
Feel free to use this quick workaround I wrote that re-centers the mesh by moving all vertices by the negative value of EditableMesh:GetCenter(). This makes the bounding box align correctly with the mesh.
local function correctBoundingBox(eMesh: EditableMesh)
local center = eMesh:GetCenter()
local deltaPos = -center
-- Shift all vertices by the negative center offset
for _, vertId in ipairs(eMesh:GetVertices()) do
eMesh:SetPosition(vertId, eMesh:GetPosition(vertId) + deltaPos)
end
end
Keep in mind that this is a pretty quick and dirty workaround. If you add or move vertices in the mesh after applying this function, you’ll need to adjust their positions manually to maintain proper alignment.
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.
