Hi, you may find this helpful as a workaround right now. We’re currently working on techniques to evict in-experience creations from memory and increase the memory budget—hopefully we’ll have some good news to share soon.
It looks like there is no image projection going on, just a single material with the vertex colors making it look like grass or snow. In theory, you may be able to have a material whose color, roughness, and normal maps are images with multiple different textures, and you could do some magic with the editable mesh vertex uvs to display different materials onto a single mesh.
Please drop the ID verification, it makes this feature utterly useless. I would love to use it for waves on other games which are not held by a id verified account.
What’s stopping someone from using parts to make inappropriate things, its completely pointless and stops Roblox engine being up there with unity with all the gated features…
6 Likes
I know this is bumping a topic that died 41 days ago however you did state this would be looked into early this year. Just curious if there will ever be any kind of update on this as there hasn’t been any changes to CaptureRegion or the ability to hide the CoreGui to protect sensitive information as previously discussed.
Only because I feel this is a really cool use of CaptureService and EditableImage API and it’s now scrapped because of the restrictions:
2 Likes
why on earth does this require ID verification?
i don’t want to enable creepy things like voice chat on roblox of all things, like, ever. ideally i don’t even want it to have access to my microphone, which is why i have never verified my age. this just ensures i’ll never want to use this feature to begin with, even if i were to go out of my way to learn the skills required to use it at all. that, and after the breech discord had, more than ever roblox and other services have no place asking users to ‘just trust them’ with their IDs if it’s not required by law.
roblox studio is so dumbed down compared to unity etc literally just so that even kids are able to learn it. now we’re going to commit so little to being proactive about the issue that you’ll just lock them out of using certain features of it instead? in what way would this be abused worse than any other aspect of it already is? there is and was already an entire genre of games dedicated to breaking tos as is that roblox has been lax on doing much about until the news started reporting on it. this is a performative measure at best, and also very annoying for anyone who doesn’t belong in jail.
2 Likes
Any updates on this? Been a year since the release.
1 Like
Allowing screenshots to be made into EditableImages would be really nice! I wanna experiment with a low fps blurred peripheral vision for “dual” rendered scopes : )
(I know I’m misusing screenshots as rendered frames, Roblox should really add a service to access the rendered frames 
)
How to improve EditableMesh
- Remove ID verification
- Allow to modfiy it in Parallel
- Remove MAX EditableMeshes limit (Like for real, this kills all initiative to work with them)
- Make more simple way to create it (It’s very confusing at the moment)
- Remove polygons and triangles limit (Only developers must decide how many there should be)
- (Optional) Create uncopyloced showcase place to show how to work with it (With more examples, not just wheel deformation)
Also please add methods for reading polygons, triangles, etc. for BaseParts
6 Likes
Thanks for the recent round of feedback.
We are actively working on solutions / alternatives for the following top issues:
- Editable* objects supporting replication
- ID verification requirements
- Memory budget limits with Editable*
- Permissions restrictions on which assets can be used with Editable*
While we would have loved to have solutions for these within 2025, some of these are actually much more difficult to address holistically across the platform (and balancing safety, stability and asset privacy) which is why it is taking a little longer.
We hope to share more details on the plans + solutions early next year.
3 Likes
What I would really love to see is the ability to assign individual textures to individual faces, for uses like custom terrain, otherwise we are forced to create individual meshes for each texture that we want to retain detail in our games (because putting them in an atlas decreases the pixels we have and makes them blurry). This is especially true for pixel style games with low resolution textures of 16x16 or 32x32, etc. And something I have been begging for a while is texture filtering options on meshes/textures/decals/materialvariants. You guys already implemented the pixelated resampling for texture GUIs, why hasn’t meshes or decals/textures not received the same?
Taking a bit of a shot in the dark here, but is this still planned for release anytime soon? There are so many legitimate and safe use cases for it, and as far as I can tell, even two years after that reply there’s still no way to transfer captured images into EditableImages.
Hey, a lot of us have still been waiting for a solution on this, and no staff has given us an update to this yet since. Any update on this at all?
Small bump, but when are we going to be able to create editable images from a temporary texture ID?
In a game I’m working on, there’s an “auto-exposure” script that basically samples the currently rendered image of the main camera using CaptureService and AssetService, and then adjusts the game’s lighting exposure based on it.
On paper, it seems very cool! But, in practice, I get repeated errors regarding how AssetService “[…] cannot currently create editable image from temporary texture id.”
When are we going to be allowed to do this? This feature has been in the works now for over a year and a half.
2 Likes
Would like to know about this too myself. I keep wanting to use CaptureService and EditableImage to make cool effects like this
I too have attempted to make one, it was incredibly barebones to the point it was literally just checking the luminance of a VERY LOW resolution version of the CaptureService result.
Unfortunately this was during the relatively short time we did have CaptureService support, it can help so much.
Really need workarounds to editable mesh memory constraints. A feature I’m currently working on relies on this, and we’ll have to scrap it due to the very tight constraints, even though we’re using fixed meshes.
Having something like this would be great!
1 Like
Another use case for captures as EditableImages, allowing users to take screenshots of problems and upload them with an in-game bug report. Would be great for beta testers and regular players reporting bugs quickly and accurately.
Just hiding CoreGui or even all UI would be a start, most usecases wouldn’t need captures of UI anyway and of course it’s a privacy and security concern.
Hey @neutrinostack! Do you know if there’s any plan by this point to render shadows for EditableMeshes? Asking in regards to my animated foliage use-case, which I understand isn’t a use-case these APIs were designed for, but it runs surprisingly well, (especially with the new bulk APIs), just without shadows 
Demo of my use-case, so you can see how awesome it is, therefore convincing you to support it : Happy Home in Viridia | Play on Roblox (I’m faking shadows here with additional, non-editable, invisible MeshParts)
EditableMeshes are a really powerful tool. It’s a shame they are behind memory budgets. There’s massive potential if less restrictions happen.
1 Like