I’d like to report a new bug. For some reason, EditableImages aren’t working on my plugin anymore.
I haven’t updated the plugin in the past month, and now EditableImages aren’t rendering. Seemingly no errors as well. And also still have the beta enabled too
We changed how EditableImages are tracked which broke tracking of EditableImages in CoreGui. I will turn off this change on Monday and fix the issue with it soon.
It’s hard to give a concrete timeline, unfortunately, but we are hard at work making the final changes to allow this to be released. For EditableImage, the last change we need to make is allowing EditableImages to be shared by multiple instances. Keep watching this thread for more updates coming soon.
I have a quick question. Now that we have proper ways to do image processing in roblox, i was wondering if there could be any chance we could get something like a StudioService:PromptExportFile() for exporting files? (e.g. .PNG file from an EditableImage, or a .TXT from strings, etc).
This would be extremely useful for some plugins I had planned
Only some methods are enabled/not locked by roblox currently. The ones that has descriptions in the documentation are 100% enabled, the majority of the api that doesn’t have descriptions are disabled since they were added a few updates ago.
Can a Roblox Staff tell us if this is going to be released before Novemeber, or December. At least indicate around what month. I have a game that is 100% dependent on EditableImage, and we’ve been waiting for it to be released without any news from anyone.
Also, It’d be very nice to have DrawText function, and if so, is it going to have it as soon as EditableImage gets released?
This is a pretty good idea. I know we plan on there being a way to upload images from EditableImages to the platform from studio plugins, so this might serve the same use case, depending on what it is. I can’t promise anything on timeline here and we are more focused on the in-experience use cases currently but I do think that EditableImage will allow for some pretty cool studio plugin use cases.
We want to support text and are investigating the best way to support it, but it is a pretty big technical challenge and won’t be part of the first version of EditableImage.
Will EditableImage be released before November though?
Currently I’ve written my own DrawText function that uses glyph data and vectors to draw text for EditableImage, although, it was pretty difficult it isn’t a very big challenge considering you guys already have TextLabel, if it were possible to connect those two that’d be great.
For text, a way to convert a TextLabel (or any GuiObject) into an EditableImage is one of the options we are exploring. It definitely would unlock a lot of use cases, but one big challenge is that we want to make sure any API we introduce can be supported on the game server in a reliable and scalable way to address in-experience creation use cases.
In the most recent Creator Roadmap that was publicly released, we had Mesh / Image APIs scheduled for “late 2024”.
We intend to keep that promise but this is a very complex set of APIs that touch a lot of the engine. This is why we are trying our best not to over-promise a specific date / month which would then lead to needless frustration.
Hello, It’s been a blast experimenting with EditableMeshes, however i encountered an issue. The “FindVerticiesInSphere” method has an argument “radius” that’s inconsistent.
The docs state that the radius is the radius of the sphere. However the verticies considered do not match with the size of the sphere in studs. However they do match the size in studs divided by two, which is weird, if this is intentional it should be mentioned in the docs.
Below some screenshot showing the verticies (in green) and the sphere in studs (blue).
If i divide the radius by two these results match
I forgot to mention that sometimes it just doesn’t find everticies at all, even if the position and radius are right, it just doesn’t return any verticies and i don’t know why. It happens when changing mesh size and mesh id (not in real time)
(Only vertex heights are being set (only remaining function) )
(Rendering with Precise settings)
Overall, the new system now prevents us developers from manipulating individual vertex colors/normals/and uvs, and now requires us to set them on a per face basis ( I dont think I need to explain why this is a change for the worse )
I would like to request for us to be able to manipulate vertex colors, uvs, and normals on a per vertex basis again, rather than by using normalIds, faceIds, and so forth
We just released an update to this Studio Beta that addresses feedback from this topic includes some performance and memory optimizations and introduces some new improvements to the API.
Please use the new topic above to continue the discussion and please keep the feedback coming.
The sample .RBXL file included in this post has been updated to be compatible with the latest updates and the known issues section has been updated to reflect the new changes