Yes, we are also making this change to CreateEditableMeshAsync. Both these changes have been completed and will be rolled out in a few weeks.
2 Likes
Are you using decals for this? For some reason using TextureContent on decals with a fully working image doesnt display anything but once I changed it to an ImageLabel for example the image is fully visible
Disheartened that I canât use this for meshes that I donât own when I really just wanted to âgetâ info about said mesh - in my case, the meshâs face colours (since the mesh has been vertex painted and I want to retrieve those colours).
Is there any chance of implementing a âsafeâ (for lack of a better term) version of CreateEditableMeshAsync that allows you to use getters only (e.g. GetFaces, GetFaceColors)?
No, Weâre only using EditableImages.
well duh but you have to apply them to a decal, imagelabel or a mesh texture
Yes, weâve used MeshPart.TextureContent. I thought you were talking about Decal and
As far as I remember,
Decal.TextureContent is not supported yet.
2 Likes
I see, thatâs a bit unfortunate, i believe theyâve also mentioned editable image support for color maps on surface appearance, although you cant even change color map during runtime via code so i dont know when that will even happen at this point
Im once again asking if we could please get a way to Clone a meshpart and its EditableMesh. Iâve made a custom solution to work around any possible memory issues by dynamically deleting EditableMeshes that arenât in priority, but now am dealing with rate limit issues using AssetService to regenerate them each time.
Some kind of caching for EditableMeshes so they donât have to be regenerated via AssetService everytime would solve all my problems
2 Likes
Decal.TextureContent is now supported! This has been released.
5 Likes
Are there any plans to extend the API permissions to any assets published on the marketplace?
I am currently working on an ad system which would allow people to display their images on billboards in my game for a small fee. In such case Iâd find utilizing the EditableImage API very useful as it offers the ability to get an image size/resolution while to my knowledge there is no other way to do so.
Eventually a new universal AssetService method which returns the image resolution by asset ID could fit my needs.
I can imagine some more possible scenarios when Iâd prefer to know the image resolution before applying it to an EditableImage or ImageLabel.
2 Likes
Is there any way to debug editable mesh collisions? I am not sure if this is broke due to a recent studio update or something that I changed in the mesh generation, but my character should be colliding with the mesh (instead I can just walk through it).
@vfx_1 Could you clarify why you need to access different image resolutions? For instance, if ImageLabel could automatically select the optimal resolution based on the final on-screen result, would that meet your needs, or are you aiming for something more specific?
Hi @SuperDadV724, normally you would enable âShow Convex Decompositionâ in Studio Settings to debug collisions. However, thereâs a known bug that prevents EditableMesh collisions from rendering properly, and we will be working on this fix soon.
At the moment, EditableMeshes donât fully support collisions. This means that after modifying an EditableMesh, you will need to recreate its collision geometry by calling CreateMeshPartAsync() with the collision fidelity that best suits your terrain chunks, even though you wonât be able to visualize the collisions right now.
Keep in mind that Roblox currently doesnât support open or other non-manifold meshes. So, make sure your terrain chunks are closed and free of self-intersections.
1 Like
Hi, @portenio
I am looking for an efficient way which would allow me to read the image asset dimensions/resolution before applying it to an ImageLabel. As I mentioned earlier, I am creating a dynamic advertisement system where people would be able to display their own images by AssetID on billboards.
However including but not limited to aesthetic reasons Iâd prefer to only allow images which fit the specific billboard display size rather than cropping or trying to fit an image which doesnât really fit the specific display.
Either a method to return the image size by AssetID or a read-only ImageLabel property would fit my needs. I am looking forward to utilise the EditableImage API in the future but as of now due to the current limitations users would not be able to display their own images even if they published them on the marketplace.
After looking around the DevForum I can easily see that such feature is quite demanded and I believe other creators would benefit from it as well.
There is a way to get around this which involves the assetdelivery API as well as a private web service which achieves the desired result, however at the end of the day I believe that Roblox could provide us with a faster and more efficient way.
Hello
Editable meshes have proven to be very useful, however, unless Iâve missed something, they have one huge drawback. You canât easily make a lot of small editable meshes without overloading the network. If I were to make blank editable meshes with AssetService:CreateEditableMesh(), I could only make around 10 on the client. If I instead use AssetService:CreateEditableMeshAsync(content, { FixedSize = true }) with a premade small mesh as content, then I can make a whole bunch of those due to memory no longer being the limiting factor, however this requires extensive use of network calls, which can very quickly exhaust the allowed limits for clients.
Are there any plans to add a fixed size parameter (or even better, an upper bound parameter) when creating blank editable meshes? Or at least a way to copy editable meshes without the need for a network call to be made?
Currently it seems to me that whenever you create a non-fixed size editable mesh, it is assumed that it will be as big as possible when it comes to memory, causing you to very rapidly run out of space when working with multiple editable meshes.
Also, in order for me to actually use every editable mesh that I create, I must make a new MeshPart with AssetService:CreateMeshPartAsync(meshContent), which is yet another network call, though at least these meshparts can actually be cloned properly without needing extra network calls for that.
Such an amount of network calls for things like this seem very unnecessary and would make things a lot easier for custom generation if they were made more local.
If Iâve misunderstood how something about editable meshes works and I can actually do these things without too many network calls, then please tell me.
Edit: Didnât mean to reply to you @vfx_1, my bad
4 Likes
This was my problem, a bug in my code was creating a hole in the center of the mesh.
1 Like
Hello! as mentioned above, the upcoming AssetService:CreateEditableMeshAsync() update (expected within a week) will support Content.fromObject as input. This allows you to create a blank editable mesh with AssetService:CreateEditableMesh(), modify it, and then âsealâ it using CreateEditableMeshAsync(Content.fromObject(editableMesh)). You can then destroy the original unbounded mesh. This enables local copying of editable meshes, eliminating the need for network calls.
Long-termly we plan to relax the budget limits in general. Please donât hesitate to report any additional limitations you may experience!
2 Likes
^Just wanted to ask again about this; I still find that itâd be extremely useful for use-cases like the one Iâve mentioned. Essentially, it would act a âread onlyâ version of the original function, but as a result, have greater permissions.
Would it be possible to take a look and see if this is feasible to implement on Robloxâs end?
Oh, alright, thatâs great news! However, what about MeshParts? As far as Iâm aware, you still have to make a new MeshPart for every new/different editable mesh and doing so requires an Async call, which I presume is a network call.
Is that limitation also considered to be removed? I see no benefit nor any security reason to only allow the creation of MeshParts through Async calls when you want to apply an editable mesh to a part.
At least something along the lines of MeshPart:ApplyMesh(editableMesh), instead of limiting the parameter to only other MeshParts. Though an even better alternative would be making the creation of MeshParts completely local with Instance.new("MeshPart") or anything else that doesnât require the network to be used.
And about collisions, as Iâve understood, you need to make a new MeshPart through the network once again just to update the collisions. Would be very useful if that was made local too.
When you convert an EditableMesh to a MeshPart, it doesnât do a network call because the data for the mesh is already locally available, in the EditableMesh. In this case, the call is Async because it needs to compute the collision geometry, which might take a while.
3 Likes