I suggest a way of doing this would be somehow allowing a developer to reference an EditableImage in a content field (though I don’t know the specifics of how this would work, perhaps a service could be added to house the EditableImages similarly to how MaterialServices stores custom materials?). Not only would re-using EditableImages become super easy, it would also allow EditableImages to be used anywhere image content is used, like:
ParticleEmitters & Beams
The other textures in a SurfaceAppearance (directly parenting an EditableImage can only change the ColorMap at the moment)
Do you haves have an estimated release date for this yet? I know there are many plans for this that haven’t been fulfilled yet, but it would be great to start using this in-game as soon as possible!
No specific dates to share yet, but we are actively working on getting this to client beta (i.e. allow you to publish experiences with it) as soon as possible!
In the spirit of transparency, here are some things we need to wrap up:
Finalizing how permissions will work (i.e. which assets can your scripts load) to prevent IP theft
Ensuring we have plans in place and contingencies to deal with safety & moderation issues
Ensuring we have a crisp usage policy for these APIs so it is clear what you can / cannot do with these APIs to keep the platform safe.
API updates / additions to address the feedback you have provided in this forum post
We plan to solicit feedback on from the community on many of these topics before the release so keep an eye out for follow-on dev forum posts that touch on these some / all of these topics.
Why make a feature to edit meshes, except you can’t use it on any mesh with bones? Even if the bones are deleted, you still can’t use EditableMeshes at all for some reason if that model was imported with bones. What if I want to have that effect on a character? To me, that was the entire appeal, I don’t even want to disclose what I planned to do because it was a very unique effect that I had made and had fully functional on a non-skinned mesh, but it wasn’t working on any skinned meshes.
For some reason, EditableMesh:AddTriangle() is returning huge ids like 12884901891, and freezing my convex hull generator in my ModuleScript EditableMeshStuff. I was stumped for a few weeks thinking I programmed my while loops wrong, but I found that even if I made a counter guaranteeing they would end at some point, Roblox will still freeze. It is occurring in a for loop within a while loop, but other than that I have no idea why this happens. The first 4 times I run it the function returns reasonable ids like 1 2 3 & 4, but it breaks in the main while loop of my function. I’ve been able to remove bad faces to stop the freeze, although this of course stops the hull from being generated.
I’m using Vector2D’s as a compact way to hold the two vertex ids of an edge together. At least I think it’s faster? Changing it to a table didn’t fix anything.
In StarterPlayerScripts I have a script called ConvexHullBall. Instead of using an actual EditableMesh, I’ve made my own class that can be plugged in its place called FakeEditableMesh. It’s missing the UV functionality, but I can modify its geometry and raycast against it. You will see it at the top of the script in the variable TestMesh. With FakeEditableMesh, it works perfectly. If I use the actual Roblox API, it breaks.
I can transfer the results of the function to an actual EditableMesh afterwards to have it rendered, which works fine?
Basically, a face id refers to an internal face, and if you remove a face and create a new one, the new face will get a new id. ids are lua numbers, and ids can be any 53-bit integer (up to 9007199254740991). It’s best to treat them as opaque, rather than relying on them being in a specific range.
It has been 6 months since the Beta release, when can we actually use them in games? Currently these have no point since you can only kinda test them. And for that 6 months, what update has been made? None. So why not just release it?
I feel like these values should be clamped up to 60,000, given this is what the vert limit is. Is there any technical reason why this isn’t possible, or am I misunderstanding how stable IDs work.
With stable ids, the id that is returned will always refer to the given vertex / face. If you delete a vertex and try to use the old id, it will no longer be valid. If we clamp to 60,000, then we’ll have to reuse ids. Having the ids be large numbers also gives us some flexibility on future performance and correctness improvements, like throwing an error if a face id is provided when a vertex id was expected. Either way, lua code will need to work with numbers that have gaps in between them, because you can delete triangles and vertices.
One piece of feedback we’ve heard is that for debugging, the huge numbers are a pain. I think we have a good solution to that in progress. Are there other reasons why the huge numbers are difficult to work with?
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
The only problem I’m having with them is lag, my script is fully optimized yet still getting 40 to 45 FPS. It would be great if there was a way of running code on the GPU (I doubt it’s even possible, but it would be nice).
How soon after release can we expect EditableMeshes to have collisions? There are some fascinating applications that are completely impossible without this.
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
