While the (upcoming) ability to both seal an EditableMesh and generate its collisions with a single method is appreciated, wouldn’t this cause unnecessary overhead if the resultant MeshPart isn’t expected to interact with anything physically? I can think of a few use cases that would only make use of the visual mesh without collision interaction, such as 3D dynamic clouds or background assets in player-inaccessible areas. As for me personally, I’ve created a custom procedural collision system for one of my terrain implementations, so having each mesh with its own collision and fluid data becomes redundant, especially if there’re meshes placed far away from the player.
I think something along the lines of this can be useful in this case:
…or at least the ability to assign an Object type to a MeshPart’s MeshId (or MeshContent) without computing collision or fluid data. I believe the original implementation did just that, with the MeshPart serving as a “visual preview” of the EditableMesh. I’m not sure how the data is structured now or whether a mesh’s visual and collision data can be decoupled like this, but provisions for swapping visual meshes only would be a great addition. Right now, it seems like a lot of extra work with having to create a whole new MeshPart just to apply (parts of) its data to another MeshPart.
So I’ve had some time to ruminate on the whole ID thing.
As I’m sure other people have mentioned here, if a bad actor wants to draw a bad image, they’ll just do it with frames, they dont care about performance. Using ID as a replacement for proper moderation feels like such a massive step backwards for this otherwise insanely powerful API.
If anything, editables would be safer to moderate than a collection of frames, since both contain their raw memory buffer as a BinaryString.
When this was first requested as a CanvasFrame years ago, this was already brought up and I dont get how it hasn’t been figured out on your end over all that time.
Is there any update on creating fixed size editable meshes? Only being able to create ~8 at runtime eliminates so many use cases for the feature, I hope it’s still being prioritized. I’m also interested in where improvements to lighting on EditableMeshes are in the pipeline. I want to create terrain with this API, and right now it’s not feasible because the feature seems wholly focused on this super narrow in-experience creation use-case. There are so many use cases beyond UGC creation, I would be very surprised and upset if they aren’t being seriously considered and prioritised by the team (as indicated by previous replies?)
I really hope they prioritize removing the limit, because I was so disappointed to find out this limit exists whilst making a custom terrain generator. This hard limit really puts a cap on the innovative uses of EditableMesh.
Every MeshPart has collision geometry, whether they’re backed by a MeshId or backed by an EditableMesh. If you’re using a different method for collision, you can’t completely get rid of the collision geometry, but you can minimize the overhead.
Specifically, when converting from an EditableMesh to a MeshPart, you can use: AssetService:CreateMeshPart( emesh, { CollisionFidelity=Enum.CollisionFidelity.Box }), which is cheap in memory use and CPU time.
Still waiting for the asset permission system to become better ive had so many usecases for editableimages and editablemeshes, which were snuffed out by the fact that theres wonky and annoying limitations when switching between user-made and group-made assets. please laxen these restrictions!
Hello! CreateEditableMeshAsync(Content.fromObject(editableMesh)) is available now, which is useful for both clone and memory management. For memory management case, this allows you to create a blank editable mesh with AssetService:CreateEditableMesh() , modify it, and then clone a FixedSize version of it using CreateEditableMeshAsync(Content.fromObject(editableMesh)) . You can then destroy the original unbounded mesh.
Thank you for the feedback! We are actively optimizing performance and will gradually increase the limits based on our analysis. Our long-term goal is to get rid of fixed limits and dynamically adjust resource usage per device. We truly appreciate your understanding as we navigate the memory-intensive nature of this feature, and hope the CreateEditableMeshAsync update above serves as a useful interim solution!
I’m very confused. Using CreateEditableMeshAsync still goes towards the memory budget. Just because it’s fixed, it doesnt change anything for me as I can only generate 8 editable meshes at a time, even with this “fix”.
Could I get some clarification if this is the case, or if I’m using the API wrong? Currently my code looks like this:
emesh:RemoveUnused()
local sealed = AssetService:CreateEditableMeshAsync(Content.fromObject(emesh))
emesh:Destroy()
return sealed
The behavior I would expect from reading your post would be that the editable mesh, in this case “emesh” once, destroyed, would be removed from the memory budget of eight, and the sealed mesh would not count towards it, essentially allowing me to generate more than 8 editable meshes, if I’m sealing them as I go. However, after generating merely 3 editable meshes using this method, it throws the memory budget error.
This is for a terrain LOD system, so once the chunks are generated, they don’t need to be edited again. I really need to figure this out for my project.
Thanks for your time!
EDIT: Apparently there is some kind of hidden triangle limit as well? I fixed my issue by lowering the amount of triangles per editable mesh.
Hi! Would it at all be possible to raise the max size limits of EditableImages in studio-only? I’ve spent the past 3 days writing a script that takes high quality in-game images of our models, however given that they’re restricted to 1024x1024, its hard to make some of them look good without losing detail or zooming in too much.
I tried this new ‘sealed’ editable meshes. It works great for reducing memory, but it appears the sealed version has issues calculating collisions. This first video shows where my player falls through a sealed mesh:
While, same code just not sealing the original editable mesh:
I am confused by the explanation about EditableImage and restrictions on free-form drawing. In a previous update it was said that Editables would be moderated and then replicated if it passed. Is it possible to have a game that uses EditableImage to allow users to draw on a surface in a game, which gets moderated and then replicated?
Does anybody know why when I draw a circle onto an editable image with a predetermined compressed size, the circle appears compressed as well? Is there a way to avoid this?
Hello! Unbounded and FixedSize emesh share the same memory budget, so, it is not like creating 8 unbounded emesh are guaranteed - we currently don’t regulated emesh by numbers. It could be the emesh you created was already big, and the memory est of its Fixed Version is still cost a lot for the budget.
FixedSize would make a big difference in the case If your object uses significantly fewer vertices than an unbounded emesh expects and converting it to FixedSize would assign it a decent memory cost instead of using the maxCost. Feel free to DM me the placefile and I can double check. Thanks!
Are there any plans for us to be able to ‘seal’ an emesh 100% so that it can’t be edited anymore and behaves like a regular MeshPart that doesn’t count towards the memory budget anymore?
I would really need this for my project.
ive had so many usecases for editableimages and editablemeshes, which were snuffed out by the fact that theres wonky and annoying limitations when switching between user-made and group-made assets. please laxen these restrictions!
