Hi everyone!
ICYMI: We announced a new API – DrawImageProjected !
This allows you to add decals and images to assets, including avatar bodies. For more information, please check out our devforum post here.
Thanks
3 Likes
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.
Oh, so you indeed used it like 1 point = 1 pixel.
I used similar approach but scaleable, and it allows twice as less sadly.
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?
The limit is per client so other clients would not be affected.
1 Like
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
Yes, this is planned:
chars
Ok very nice thanks for the response
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?
1 Like
does calling :Destroy on an editable mesh reset its FixedSize property?
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?
1 Like
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.
1 Like
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.
1 Like
Welllllllllll It did break one of my things. Specifically my ray tracers. To get around the 1024x1024 resolution limitation was to just create multiple smaller editable images and stitch them together. When i actually try rendering, only one editable image will update at once while all the rest remain stuck. Here is a clip of that:
I get the idea behind the performance issues though my only alternatives here are ImageLabels which we can all agree that those would be a million times more demanding.
Is there at least an fflag i could modify right now?
1 Like
Sorry this broke your code, this limit did break backwards compatibility with the previous studio beta. We want to avoid any further breaking changes after releasing EditableImage to clients which is why this limit is so strict right now. We realize that there is room for improvement and want to make it better in the future.
1 Like
Because recalculating the collisions can take a while, it is not done automatically. Depending on your situation, MeshPart:ApplyMesh might be the easiest way to do this.
-- assume that previewMesh is the MeshPart that's in the datamodel, and emesh is the EditableMesh
local newPreviewMesh = AssetService:CreateMeshPartAsync(emesh, { CollisionFidelity = PreciseConvexDecomposition }) -- or whatever CollisionFidelity works for your case
-- to make sure that the scale is the same after ApplyMesh
local oldRenderScale = previewMesh.Size / previewMesh.MeshSize
local newSize = newPreviewMesh.MeshSize * oldRenderScale
previewMesh:ApplyMesh(newPreviewMesh)
previewMesh.Size = newSizeWe will make the above method work, it does seem like the cleanest near term way to support clone and should work intuitively since this takes Content.
As a temporary work around, you can create a new EditableImage and use DrawImage to draw the image you want to copy into that.
3 Likes
Is there a way to bake the EditableMesh onto a MeshPart if I don’t intend on changing any of its vertices again?
I’m generating some meshes at run time, which I never intend to change the vertices of, however, I quickly run into the Failed to create empty EditableMesh that was requested due to reaching memory budget limits. warning (as I am making quite a few of these).
If I do emesh:Destroy(), it removes the visible mesh, even though the collision box is still there, but I want to be able to see the mesh and collide with it; is there a way to mark an editable mesh as non-editable in order to free up more memory?
Thank you.
3 Likes