I’ve just never grasped stable IDs that well, I’m trying to make a library that abstracts verts and tris into structs that make them a little easier to work with.
So just to make sure, if a vert/tri is deleted, the id no longer represents that vert/tri?
I swapped pairs to ipairs where I could. But it still froze, I found the solution though!
Each face can be assigned a list of points in my code. These point lists are in a table, and faceId’s are used to index the list belonging to each face. The large face id’s must have made Roblox try to allocate some humungous array, freezing my PC. I changed this to convert face ids into a string so that I was using dictionaries instead of arrays, and it worked!
Right, a vert or triangle id refers to a specific internal vert or triangle. Once you remove that using RemoveTriangle or RemoveVertex, the id isn’t useful, because what it used to represent no longer exists. If you add a new triangle or vertex, that will have a new id.
Absolutly loving this feature! I hope they’ll release soon because I’m working on a game and planning on using them for effects and such
FYI you don’t need a iterator function at all, you can just iterate directly on the function output
How soon after release can we expect EditableMeshes to have collisions? There are some fascinating applications that are completely impossible without this.
Until roblox implements the ability to create and run custom shaders, your optimization is going to stay where it is.
I bet i could get that to run +60 fps
How would you do that?
charrrr
Been using editable meshes for a while now on a project me, and fellow programmer @telnetbomber have been working on
Have found some little oversights with the system that reduce the developer experience quite a bit
The major one is the lack of texture options for editable meshes (due to MeshPart.Texture not working with editable meshes for some reason…), with EditableImages and SurfaceAppearances being the only option at the moment
This isnt ideal, especially for textures that could be prone to change, and editableImages are extremely expensive on memory, and SurfaceAppearance ColorMaps cannot be changed in the script environment (stopping dynamic texture changes, such as changing texture packs for a voxel engine)
Another issue is triangle-precise collision. Currently editable meshes dont support preciseConvex colissions, and just use the mesh bounding box, which leads many developers such as myself to have to write their own collision handlers for more ambiguous projects
Overall, great feature, but there could be some improvements to improve UX
On a side note, when are we seeing more integration of NearestNeighbour aliasing on more texture objects; we have them on UIObjects but not on meshes, and other classes that utilise image textures
Furthermore is there an ETA on editable mesh release? I have a project in the works that uses editable meshes as a baseline for terrain generation, so would be nice to have it out of Beta before then!
current project is using surface appearances, because MeshPart.Texture doesnt work with EditableMeshes
Im known for optimising the heck out of image processing and custom renderers.
Here’s a couple of my best most optimised projects:
I think i can definitely find a way to improve performance with yours somehow
This is the code that makes the effect, I pretty much just pasted it from a tutorial I found online. I’m curious how you could optimize it even further
local size = editImg.Size
local pixels = editImg:ReadPixels(Vector2.zero, size)
local frames = 0
local pi = math.pi*2
local stride = size.X * 4
local sy = size.X
local sx = size.Y
local sin = math.sin
local round = math.round
local zero = Vector2.zero
local function run()
local newPixels = {}
frames += 1
local t = frames * 0.1
for y = 0, sy - 1 do
for x = 0, sx - 1 do
local xs = round(sin(pi * (3 * y / sy + t)))
local ys = round(sin(pi * (3 * x / sx + t)))
local dest = y * stride + x * 4
local src = ((y + ys) % sy) * stride + ((x + xs) % sx) * 4
for i=1, 4 do
newPixels[dest + i] = pixels[src + i]
end
end
end
editImg:WritePixels(zero, size, newPixels)
end
runService:BindToRenderStep("imgEffect", 1, run)
Can editable images currently be used in production?
edit: Nevermind, just saw the official post. So likely a few months
Are there plans to create a write pixel method that uses raw numbers for size and position values and u8 buffer of pixels to write? (or maybe u16/f32, since these have better precision for your post-processing needs)
Why? I think it can help improve the performance by a margin, since the overhead of creating Vector2’s will be removed and also the fact that buffers are typically fast compared to other ways of storing and writing data.
Fun mesh slicer I have been working on:
Though I seem to have reached the limits of EditableMesh. Few slices in and EditableMeshes becomes highly unstable, cloning would fail and adding triangles would cause engine crash.
I had a difficult time trying to isolate the issues for a bug report, but if any engineers wants to take a look, I would be happy to provide the place file.
With 8 threads I got it to run at 60 fps for a 512x512 texture.
If you do most of the heavy lifting in parallel you can get some pretty impressive results.
If you have a stress test and you’re regularly seeing crashes or other instability, that’d be very useful.
Thanks 
I have sent you a private message!
Time to make fruit ninja and beat saber!
My game relies on EditableMeshes for some critical parts of the game, and I’m unable to test in live servers right now. Can we get an ETA of when they will be released?