Edit, this appears to be due to the offsets my code produces for the vertices prior to mesh creation (although I’m not entirely sure why it respects this, but doesn’t respect the scale of the shape)
I seem to be running into an issue with positioning my Mesh. While not a perfectly flat plane, it is a relatively flat plane with a small y-value introduced just so it can render appropriately.
In this image, the bottom left is the first vertex/normal made, the top right is the last vertex/normal made (as annotated by the green/red visuals). One would expect the center vertex to be the center of the bounding box either way, but if I create a part at MeshPart.Position (the black normal) the MeshPart is obviously off-center and I’m not sure why.
This can also be seen in rotations. For example, a 180 degree rotation about the y-axis with no translation, translates the object from it’s initial position (because it rotates about the center point which is positioned incorrectly).
The main problem is what is being stored in the datastore isn’t guaranteed to really be a capture since it’s coming from the user’s client. Showing this to other users without it going through moderation wouldn’t be safe.
There are ways we could potentially support this in the future without saving unmoderated images from clients, for example we could allow you to turn a ViewportFrame into an EditableImage on the RCC server and it would be safe to store this in a datastore because it is produced on the RCC server.
That would be cool, though ViewportFrames have a lot of limitations at the moment, e.g. being unable to render particle effects or UI objects, and having very limited lighting features, so for complex creations it might not work very well.
Trying to replicate an EditableImage from client to server in any other use case would have the same moderation problem as well.
Theoretically, wouldn’t all of this be allowed under the “Free-form user creation” content descriptor?
Hey thanks for reporting the error. Can I get more detail on the context, i.e. the script is loading many different assets at once, or loading the same asset again and again in a short period of time?
There is still a spectrum of ways that EditableImage can be replicated between clients where some ways will be safer than others and less likely to run into issues. For example, if you implemented a drawing game, you could replicate the final produced image to the server or you could replicate the brush strokes as the image is being created and draw it on the server too. I would recommend replicating the brush strokes instead of the final image because you can validate things like brush size to enforce limits on what is actually being produced to prevent the worst type of behavior.
Currently, we don’t allow captures to be put in EditableImages due to some privacy issues. In the future, we want to support adding captures that don’t include UI into EditableImage or something like that (Exact solution tbd). This work coordinates well with some capture-sharing work we want to do next year, but I can’t promise anything timeline-wise, unfortunately.
Hello! It’s not possible yet. However, we are planning to add options in the future that will allow you to specify a maximum number of vertices or triangles for an editable mesh. Additionally, we’re considering the ability to treat an editable mesh as content for AssetService:CreateEditableMeshAsync() to “seal” it.
In the meantime, if you’re concerned about memory usage with unbounded editable meshes, one workaround is to merge multiple editable meshes into a single, larger one. You can then use Destroy() on the previous meshes to reclaim memory.
Hey this should be fixed in the newest Studio version 653 and above. Again command line and plugin is allowed to use in Studio edit mode with this fix. It still requires ID verification and toggle button to use it in Studio play mode or in production.
Let me know if you have any further comments.
Every time game starts up I grab all tagged mesh parts and load them in via CreateEditableMeshAsync, after starting up the game few times, it starts to throw those errors. I need this API so I can generate proper colliders.
I appreciate the response, but I’m slightly confused. What is the privacy concern exactly? Considering the fact that CaptureService allows users to store and share their captures using the exact same system… or at least that’s what the docs suggests.
The concern is that currently captures can contain sensitive information such as the users Robux balance (for example if the purchase prompt is on screen).
Allowing EditableImage to load captures would indirectly allow this information to be read without requiring that the user wants to share it. i.e the current prompt system allows users to choose if they want to share an image, but EditableImage would allow developers to directly read the pixels without user confirmation.
Early next year we will look into addressing this either with a prompt API for developers to load the content into an EditableImage or by improving how we hide CoreGui in captures so that developers can load the captures into EditableImage if the CoreGui is hidden.
Unless a prompt is absolutely necessary for security reasons, the latter option would be best. I feel like there are plenty of use cases where a game would want to silently take screenshots, and requiring the user to accept a prompt for the game to load it into an EditableImage would break that flow.
While on the topic, would it ever be possible to save an EditableImage into the user’s captures gallery?
I’m getting a bug in studio - about 25% of the time, when I hit run, it will error saying EditableMesh API is not accessible for security reasons, even when it has been enabled.
I’ve seen this message at least 30 times over the past day and it’s been getting really frustrating when I just try to do a quick test to see if my code changes work.
Seconding this!
I’m encountering the same issue in my game, I have the mesh and image APIs enabled in security and I am age verified but it appears to randomly throw the error. I’ve also encountered the error one time while play testing outside of studio.
I am also getting this error and it is happening quite frequently and it is pretty annoying. I have the mesh and image APIs enabled in security and I am age verified.
Edit* This appears to be the case for all textures / meshes in roblox and not just an issue with EditableImage/EditableMesh.
Edit 2/3* If you take the image size you were going to use and dedicate the first row/column and last row/column in every box subdivision, you can remove the automatic interpolation between colors for those (while still having interpolation within the box)
E.g. You need a 128x128 texture with 8 x 8 boxes inside. You then have 64 16x16 boxes, of which you only use 14x14 pixels and the first row/column and last row/column are reserved to block interpolation (both wrap-around and between the other boxes).
Original Message:
I seem to be having an issue with precision in EditableImages
In this example I have a single image 128x128. I split it up into a set of 64 buffers of size 16x16. I then wrote a single one of the buffers to the image and then set the TextureContent of a Mesh. The mesh is a plane made of 4 vertices.
At first glance everything looks perfect, I have my square.
But then looking at the other corners of the plane, I can see part of the square.
This makes the first row / column and the last row / column in the texture worthless because the colors will unexpectedly show up in other parts of my meshes where I don’t want them to.
How should one approach procedural meshes that need different images each?
I am making a creature survival game and the creatures are procedurally generated, I wanted to use the EditableMesh instance but the imposed limit right now is too limiting, I am waiting until better options are ruled out, though I will have to make a check beforehand and kick any player who does not have enough memory to run the necessary EditableMeshes.
I used my own skinning system to animate the vertices, but I would like to replace that with the weight editing system that is to come, my main concern is that I do not want to generate a new asset for every new creature that is made. Does Roblox plan on adding any sort of “temporary” mesh creation for Editable Meshes that needn’t be turned into collision-accurate meshes?
