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?
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.
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 = newSize
We 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.
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?
Are there any plans to lift PluginSecurity from MaterialVariant & SurfaceAppearance? Not being able to use EditableImage on those objects severely limits its use case for me, to be honest I cant think of a single reason to use EditableImage in my experience because PBR editing is impossible.
We plan to add support for using EditableImage with SurfaceAppearance.ColorMap soon. Full PBR support is quite a challenge, but itās still something we are investigating and want to support in the long term.
My main use case is something like procedural normal maps for things like water, but it could also just be used to create a wide variety of animated materials. I also understand the performance of EditableImage still needs some work.
This is just a developer convenience note, but for all the APIs that take multiple IDs (SetFaceUVs, SetFaceColors, etc.) when they receive an invalid ID, it would be amazing if the runtime error would indicate which ID was invalid (face ID, color ID, vertex ID, etc).
The current error of āInvalid idā does not help much, especially when it is some obscure edge case that is difficult to reproduce.
Will we ever get the option to change Sampling mode on EditableImages applied to EditableMeshes? It would be great to apply pixel art onto cubes, like in Minecraft, without having to upscale each texture, or having the texture blurred.
A fix is planned, but it requires reworking how the data is stored in the EditableMesh, and may take some time. I wish I had better news, but I canāt give a good estimate for when the fix will be available.
Are there any plans to allow developers to draw a subsection of an EditableImage onto another?
Hi, could you provide a use case for this request? That would help us to understand how to support it better or how we can adopt other functionalities that are on the roadmap.