Thank you!!! I still have optimizations to make (as you can see with the gif that took super long) but Luau seems to handle it extremely well! I’d say the part that takes the longest (as of now) is turning all of those color indexes into buffers that I can use to write on the screen. Hopefully I can find a good method to speed that up!!
music is “difficult to see” by dreamstation btw :D’
Im afraid its not possible, i tried that too and got a maximum of 8 too. A workaround i found is to basically create those 8 editable meshes from the beginning, Then you are just limited to use those meshes until it reaches the max polygon count
Yes this will be possible in the future.
hey so i tried verifying myself for the first time and its so bad
a selfie AND government issued id, just so I can use the already nerfed editable api???
I’m not gonna give roblox all that, theres no way
due to this experience I am now in agreement with you lmao
I’m aware, they have talked about it, however I’m not sure how performant that will be. Maybe the process of going from Editable > Static > Editable wont be that taxing as I assume it will be. This is especially important when you want to have a world that can be changed by the user at their will without much delay.
I don’t like the fact that we are being told “yeah it will be possible in the future”. As if it wasn’t very possible before they imposed this “dynamic” memory budgeting system. Not to mention they released this with such a vital feature missing. It really should have just been delayed.
It’s an amazing feature with a lot of work put into it, but these recent decisions are very questionable and disappointing. I’m honestly surprised nobody is talking about just how criminally limiting this feature is now compared to before. I’m honestly considering making a post about it.
Is this the same issue as the one in the below video? It looks like the same thing but with occlusion culling, but this is in a published experience, outside of studio.
Is there a way to create a fixed size editable mesh without using a URI?
If i use FixedSize = true when using AssetService:CreateEditableMesh(), would it just have a fixed size of 0 vertices or how would that work if there is no way to describe how many vertices I want the editable mesh to have
Or is this not possible yet
Just curious, for whenever if it even will: when will this not require id’s, also would it be possible to somehow store an editable image in a datastore so we could turn captures into like a photo album?
In the future, we are planning on supporting sharing captures to the platform and allowing you to reload them in game to display for use cases like this. We wouldn’t want you to store this in DataStores because it would be unmoderated and having the captures shared to the platform would allow this to be supported in a safer way.
In the future, consider a better security system or whatever you did, they damaged the API and the beautiful uses that could be given to this. A new disappointment from the Roblox team. I looked forward to each update of this API, but they come out with this and make you lose jobs, they limit your use if you are not verified and you cannot use other people’s assets. Anyway, Nerfing the Roblox engine.
I think there are valid use cases for wanting to save an EditableImage from a capture into a DataStore, such as generating thumbnails for user creations. Being forced to interact with an out-of-place CoreGui modal to upload a random capture whenever you want to save a creation in-game would be pretty awkward UX.
Cool! But would this require an additional prompt / one different from the normal save to device one, since if theres one that works similarly to normal one as a sperate method it could be nice so it saves to the device and uploads to roblox? but again this feature isnt even out yet so i doubt you’ll know
During the early beta of the EditableMesh & EditableImage API I made a camera system which utilises the CaptureService feature, uses CreateEditableImageAsync() from the capture and crops it to the capture region (in this case a phone) however I’m now getting the error “CaptureService: Unexpected error while invoking callback: AssetService:CreateEditableImageAsync cannot currently create editable image from temporary texture id.” this system is paramount for a revamp of my game as it was one of the key features to set us aside from other games. Is there any other methods to achieve the same results?
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.
Similarly, when looking from the direction of my faces, you can see that the black part is obviously way off:
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.
