Hello, thanks for the feedback! What’s the specific use case driving your need for over 100k triangles or 2-3GB memory usage?
Please consider a “read-only” version of the method that has heightened permissions 
(i.e. When you just want to fetch something from the mesh and not alter it)
1 Like
This is something that we considered, but unfortunately there’s not much advantage, because it is easy to copy the contents of an EditableMesh into another EditableMesh. The permissions issues you run into are the same. We’re investigating other ways of fixing the permissions issues to enable more use cases.
2 Likes
Not sure if this is intentional, or if I should create a bug report for it. However after deleting a face, it seems to break the entirety of RaycastLocal and results in it only returning nil?
Not intentional, a bug report is appreciated. Thanks for the heads up!
Being able to create fixed size versions is helpful, but not enough. We need the ability to bake an edited image/mesh into an ephemeral asset that benefits from the same compression as regular un-edited assets.
I am aware there are plans to be able to upload assets from editables, but the latency for that is far too high and it’s unsuitable for procedural assets that won’t ever get re-used. We need the ability to compress edited assets entirely locally.
3 Likes
Was so hyped for this, my character creation system was going to be similar to the one starfield and fallout 4/76 uses for body creation but with a anime styled rig. The id verification has kinda given me a reason to look for other options, might have to make a external tool to auto generate each possible combo and upload them individually
It would be very useful if we could save the mesh to memory in the same way as any other mesh. Unfortunately even with the trick you describe, you only need a few tens of fixed size meshes to reach the limit. I’m not sure how it works under the hood exactly but I can’t see any reason to limit the number of meshes provided the conversion is one way (i.e. you can’t create an editable mesh from a locked mesh)
In its current state the API is borderline unusable because of this, unfortunately 
Edit: ah just noticed this bit:
We plan to provide an efficient option to use runtime-generated images and meshes once you are done reading or editing them, without needing to publish them, similar to in-experience Solid Modeling (CSG).
I take it this is something in that vein? Do you have any idea on the rough roadmap for this feature?
I can see that editing existing meshes is useful, but IMO the dynamic creation of meshes is by far the most useful part of this feature, and currently terrain generation etc. just isn’t possible with the current limits
1 Like
Posted a more detailed bug report already but sending it here just in case
Switching from EditableImage to asset id on an ImageLabel or any asset supporting Content values doesn’t work / the ImageLabel keeps the EditableImage content
code ran in console :
7 Likes
Hello, currently experimenting with the API and thanks for everything so far.
A problem I’ve been having is not being able to flip the normals.
How could I flip the normals? I tried AddNormal(Vector3) method but that didn’t seem to work.
Thanks!
If you want to turn the face over so that it is not transparent. To do this, you need to change the order of the vertexes in the triangle. And the opposite normal vector can be obtained by multiplying by -1.
1 Like
Hi, Is there any way to apply an EditableImage and then reuse it on another ImageLabel?
Im creating a bump effect using EditableImage, and since it requires multiple images, I was wondering if I could apply the changes once and then reuse the result on other image labels.
Yeah just set the ImageContent value of all the ImageLabels to the same EditableImage and they will all update when changes are applied to the EditableImage
I want to use one EditableImage for multiple ImageLabels, but I need each ImageLabel to show a different version of the image. Right now, when I change the EditableImage, all the ImageLabels update the same. How can I make each ImageLabel show a different modified version of the same base image?
Unfortunately you will have to create a new EditableImage and apply changes to each individually for every different version
Thanks. Hopefully they add the feature to apply EditableImage someday.
I know I’m late to this party but since the last time I’ve used these there’s been a memory budget on the EditableMeshes which is super frustrating. It should be up to the developer to optimise their games for their audience, not Roblox’.
I had some really nice Earth generation code a while back which is now broken due to the new memory limits. Super bummed
After a year of this feature being available, I decided it was finally time to implement it into a game.
I was excited to try it after seeing on the forum just how powerful this feature could be.
Unfortunately, after implementing it for what is likely one of the most common use cases - vehicle deformation on crash - the feature currently isn’t usable due to the following issues:
-
Low memory budget:
I use vehicles with an average number of vertices compared to other games (around 20k), and my game supports an above-average number of players (50).
This means I would need 20k * 50 = 1m triangles across EditableMeshes for the server’s budget.
(Not sure what the actual server budget will be, but the client-side limit is already too low.)
Possible solutions:- Increase the memory budget for EditableMeshes
- Allow meshes generated by EditableMesh to exist independently of the EditableMesh object itself. This way, I could keep the EditableMesh only during a crash and destroy it afterward.
- No shadows for MeshParts created with EditableMesh
1 Like
One question, can the collision change in real time?
Very good points and a good summary of some of the major issues devs are facing right now.
We are actively working on addressing these issues. The current leading candidate is:
- Allow meshes generated by EditableMesh to exist independently of the EditableMesh object itself. This way, I could keep the EditableMesh only during a crash and destroy it afterward.
… that would solve a number of dev issues above as well as set us up for future capabilities that have been in consideration
1 Like