Yes.
This is a feature that is in progress, but it is difficult to give an estimate for when it will be available, unfortunately
1 Like
@TenTheWarrior / @bytesleuth Iām curious what you are hoping to do with EditableMesh + Skinned Meshes. Iād love to understand more about your scenario.
1 Like
I want to get the position of a random vertice on my skinned mesh.
Absolutely in love with whatās possible using EditableMeshes/Images.
The only thing I wish for is ānearest neighbourā upscaling so that we can finally use pixel art in our games without having to upscale and lose out on performance.
18 Likes
Is RaycastLocal going to become Parallel safe? It seems a bit silly to be that something that could have so much potential (especially as a raycast) isnāt Parallel safe.
1 Like
Outside use case, but being able to adjust UV coordinates at runtime to make scrollable textures on a skinned mesh ocean.
1 Like
Iāve realized my EditableImages use a high amount of memory. Iām using a total of ~800 static 256x256 EditableImages parented to EditableMeshes resulting to 600+ MB of RAM used.
Is this an expected amount of memory for EditableImages to use?
Additionally, will it be possible to set EditableMeshās texture directly instead of having to create an EditableImage to override the texture property?
In my use case, Iām not modifiying the EditableImage, but cannot directly set the texture of the EditableImage directly, not sure if thatās expected behaviour either.
Can you provide more information about your use case? Are these 800 EditableImages all different or are some of them duplicated?
The first EditableImage is created using
game:GetService('AssetService'):CreateEditableImageAsync("rbxassetid://id")
The rest of the 800 of the EditableImages are clones of the first one, parented to a MeshPart as shown in the picture below.
Not sure if this impacts EditableImageās performance but each EditableMesh has ~couple thousand UV points set.
3 Likes
In the future, we will allow EditableImages to be shared amongst multiple consumers and this will allow for the memory usage to be much lower for use cases like this.
14 Likes
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)
- MaterialVariant textures
- and possibly more?
5 Likes
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!
2 Likes
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.
7 Likes
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.
1 Like
AddingFacesBroken.rbxl (73.9 KB)
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?
1 Like
Thanks for the sample rbxl - I think the problem is that the code is using pairs instead of ipairs?
If youāre wondering whatās going on with the ids being very large, I wrote up a bit about it here: EditableMesh:RemoveVertex on a mesh with 1 vertex causes a 32-bit overflow
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.
1 Like
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?
1 Like
Will the release version of editable meshes support glass distortions?
1 Like
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.
1 Like
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?
1 Like