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.
2 Likes
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
8 Likes
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
2 Likes
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
Teh code
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)
2 Likes
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.
1 Like
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.
8 Likes
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.
14 Likes
If you have a stress test and you’re regularly seeing crashes or other instability, that’d be very useful.
Thanks 
1 Like
I have sent you a private message!
Time to make fruit ninja and beat saber!
2 Likes
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?
10 Likes
is there/will there be a way to add autosmooth (or even shade smooth) to meshes?
By default currently when you make a mesh the normals will be smooth. Making a smoothing operation would also be possible, but there isn’t a current plan to create that function. How would you want it to behave, and what is your use case for it? Thanks!
1 Like
shade smooth and auto smooth end up looking very different, and some of my models depend on this (for example auto smooth helps hide the split vertices on the seams of my model shown below)
also, will there be any support for ordered vertices? i was kinda let down when i realised blendshapes were not possible
5 Likes
We don’t have plans to add shade auto smooth to the API, but I think it should be possible to do in lua, I’ll take a shot at it after I finish my current chunk of work (may be a week or two)
6 Likes
Is there any way the finished api will return data organized in a more efficient way?
For example, I have a system that performs many repeated operations using vertex positions & other stuff. What I do is have a table set up like this: { [VertexID]:VertexPosition }
This means it is much faster to grab a vertex position because now I can just use the table rather than a function. The issue with this is that I have to go through all vertices (Mesh:GetVertices) and grab their position (Mesh:GetPosition) initially to set up that table, which is very slow, but the result pays off because it runs much faster afterwards.
What I’m asking is if we can get a function like :GetVertices except it’s already laid out like I described above. Which would allow you to do code like this much more efficiently than before:
for VertexID, VertexPosition in Mesh:GetPositions() do
--stuff
end
--and also grab vertex positions by doing Positions[VertexID] which is much faster
This is only an issue because doing (:GetPosition) in a loop through all vertices in lua can take a very long time for what it is. Also just doing it repeatedly.
2 Likes