Thanks for catching this. The Hubcap demo in the post has now been updated to match the recent release. Please ensure you are using v24
of the rbxl file.
Apologies for the change, and that it took a while to track down - it looks like the flag that controlled it was accidentally disabled . It will be re-enabled on Monday
Thank you! I didn’t understand what was properly needed for the new AssetService system, but after referencing the updated place file my code works again
Suddenly completely broken for me. This code to generate your own meshParts no longer works and returns an error.
– Create a new MeshPart instance linked to this EditableMesh Content
– Note: EditableMesh:CreateMeshPartAsync will be replaced with
– AssetService:CreateMeshPartAsync(Content, …) before public release
local newMeshPart = myEditableMesh:CreateMeshPartAsync(computeExtents(myEditableMesh))
It was replaced with AssetService:CreateMeshPartAsync(), but attempts to use that wind up becoming restricted to the mesh of the existing mesh part instead of allowing you to programmatically create your own meshes.
Will the ability to create EditableImages via rbxthumb://
be brought back any time soon?
FastCluster bug fixed, thank you so much!!!
It’s just that the intense lag from setting position on the editableMeshes came back
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.
Yes it is a perfect 2d plane on the X and Z axis
@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
ngl the FastCluster glitch be trippin’
the meshes are no longer rendered inside a humanoid … again.
I’ll wait, not bothering the editableMesh devs cause I think they be doing crazy work😭
Would you be able to DM me this place file, and I can take a look?
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.
Re-enabling this is a good idea, I think we should be able to do this.
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.
Thanks for the bug reports.
We’ve had a few people ask for an EditableMesh:Clear
method, and with the changes to how preview works for EditableMesh, it seems more useful.
In the meantime, you can clear an EditableMesh using:
for _,fid in emesh:GetFaces() do
emesh:RemoveFace(fid)
end
emesh:RemoveUnused()
This will remove all faces, vertices, normals, UVs, and colors.
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
without anything ontop
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.