For erasing things, there are a few options:
You can use Enum.ImageCombineType.Override and a transparency of 1 with EditableImage:DrawCircle or EditableImage:DrawRectangle.
For something like EditableImage:DrawProjectionImage you can use Enum.ImageCombineType.Multiply and Enum.ImageAlphaType.LockCanvasColor with pixels with no alpha where you want to erase them.
A more explicit erase option is something we could consider but I’m slightly worried about some inconsistency in how it would work for the primitive drawing methods vs the more advanced drawing methods might make it confusing.
Custom combine types would be hard to implement in way that wouldn’t have too much performance overhead for crossing the C++ to Lua bridge for every pixel.
How would I use Enum.ImageAlphaType? I was assuming at first that it would be included in the options dictionary for EditableImage:DrawImageTransformed, but at the moment its usage is not documented anywhere.
ColorSequences can store 20 different color values. So if you make the gui 20 pixels long then each “part” of the gradient is perfectly distanced. I assumed it would have some weird interpolation issues but no it’s looks great.
When it comes to the EditableImage memory limits, how does it apply to client-side only objects? Say I use up the memory on one client for UI, would another client be affected by those limits?
This is a question from a 2 year old reply to the original announcement that was never answered and I am still interested if there will be plans to expand EditableImages to be used on more properties, like,
Beam.Texture
ParticleEmitter.Texture
Trail.Texture
ClassicShirt.ShirtTemplate
ClassicPant.PantsTemplate
ClassicTShirt.Graphic
Material.ColorMap
Tool.TextureId
Sky textures
For me I am most interested in the ShirtTemplate and PantsTemplate integration
Hi, is there an update on meshes with Precise Convex Decomposition CollisionFidelity taking a very long time to be created?
Any estimated timeframe for a fix?
I see a lot of people posting about using editable meshes for terrain generation. I am trying but the collisions seem to be off. Is there some way to recalculate the collisions?
Note: I am using CollisionFidelity.PreciseConvexDecomposition which only appears to calculate the collision box when the mesh part is created and does not update as the editable mesh is changed.
Further Note: I updated my Roblox Studio and see a whole new behavior where my player now walks up some invisible object and then falls.
I’m noticing that multiple EditableImages are incapable of updating their visuals at the same time within a single frame. Is this intended behavior? If so why?
I’m not sure if this is a bug or would be categorized as something else.
I was attempting to clone a editable image by doing the following:
local AssetService = game:GetService("AssetService")
local editImg = AssetService:CreateEditableImageAsync(Content.fromUri(...))
local copy = AssetService:CreateEditableImageAsync(Content.fromObject(editImg))
However, I get the following error: Failed to load texture
I’m curious if we’ll get a proper clone method or if the above method should work?
I would say that this is semi-intended behavior. It’s a known current limitation but something we want to improve. Updating an EditableImage is expensive from both a memory and performance perspective as we need to have another copy of the image and then send that over to the GPU on the rendering thread. Because of this, we currently have a hard limit of updating 1 EditableImage per frame to limit any potential performance or memory usage issues.
In the future, we want to make this and other memory and performance limits that EditableImage currently has more dynamic, so on higher-end devices or in experiences with less going on this limit can be throttled up. We wanted to start with the minimum limit so when we released this sort of dynamic throttling, we wouldn’t be breaking pre-existing stuff.
