they can be used to texture meshes. Think procedural changes to textures (making materials appear slick during rain by modifying the roughness for instance), user paint jobs, blood splatters, and so on! The possibilities are endless if it can be made decently performant.
2 Likes
i was shocked to see in the API trackin site that some Instance were removed after the new Editable APIs, so to clear my confusion, is Object meant to be used for other services if some Instances that has its use for specific doesnāt often use Parent property since most of it wont involve using that???
i know this might sound off-topic but my first thought about Object introduced was to replace Instance for performance
1 Like
We already put a lot of trust in devs. Server ā Client replication isnāt all that controversial. Like you already pointed out, we all already know itās equivalent expressive power to whatās possible with frames if you just squint a little.
Whatās controversial is specifics to policy around replication of user driven creation. Best practices, accountability, attribution, etc.
We should have some more clarity on this before the public release.
9 Likes
Content.fromObject should be available now. Sorry about that.
2 Likes
It canāt be used for user paint jobs if it canāt replicate, unless you write the replication AND data saving yourself.
3 Likes
I have to agree, any offensive thing you could have happen in replication from server to client with these, is already possible with part and meshpart instances going from server to client.
I actually canāt see how this replication would be any more or less ādangerousā. It will, however, be limiting creativity with these new editable*
2 Likes
what is the point of the type system if youāre just gonna {[string]: any} this stuff? at least with the Instance.new method we knew the properties
honestly do prefer it being Instance.new-able since thatās what my project was depending on and now i have to rewrite it with this untyped monstrosity of an api
1 Like
Weāll add proper definitions for these options tables and fix the autcomplete as soon as we can. You would not believe how hot some of these changes are coming in. 
Also Instance.new was not even an optionā¦ because these arenāt Instances.
2 Likes
Really looking forward to messing with this!!!
but Iām not sure if Iām doing something wrong, it seems that weāre not actually able to use CreateMeshPartAsync() like how itās shown in the code snippet?
I was also unable to test out the hubcap rbxl properly due to not owning the mesh, Not sure if itās affecting anyone else or not.
2 Likes
I know, I meant the before one. Thanks for getting to the types though, that was my main issue since I have gotten the Instance.new replacement handled though!
1 Like
myMeshPart:ApplyMesh is probably what you want, you did myMeshPart.ApplyMesh.
1 Like
EditableMesh:CreateMeshPartAsync(meshSize: Vector3, options: Dictionary?)
Has a required first argument for MeshPart.MeshSize. Idea was you would either pass in the size of the EditableMesh and update the Size of the part to match or pass in existingMeshPart.MeshSize if you want to maintain stable scale without changing Size when updating physics data on an existing mesh part.
Silly idea, my fault, sorry about that.
With the update to AssetService:CreateMeshPartAsync next week this will move to the options table and become optional. The default value will be the size of the extents of the mesh.
2 Likes
Iāve been working on a texture editing plugin since the last Editable Image update. Iāll most likely have to apply a lot of changes to adapt to the new format but Iām happy to do so.
Iām also happy to see there will be a PromptCreateAssetAsync API for Editable Images, that ensures my plugin wonāt be useless haha
But I wanted to ask a few questions :
- Will there ever be Editable Image support for VFX objects such as Particle Emitters or Beams?
- Will the size limit ever go beyond 1024x1024?
- Is studio gonna be able to get past the group permission check for creating Editable Images?
I can understand how those 3 would be trouble in-experience but I believe for studio only use cases like my plugin, lifting those limits can only benefit users. Users will get more freedom to generate higher quality assets using tools within Studio and will be able to preview their edited textures before uploading them as assets to Roblox, which gets rid of useless test uploads.
17 Likes
Please try reopen Studio and reload the hubcap rbxl again. This demo asset should be whitelist now.
2 Likes
Ah oops! It seems though that the code snippet has this error too, so hopefully thatāll be fixed so thereās less confusion!
3 Likes
Iāve noticed that using the latest EditableImage api causes a performance issue (or atleast for older methods).
Lately Iāve been making a raycast engine with the api, using DrawRectangle for each pixel to develop the image
Before this update, I was getting double the framerate compared to afterwards
Before:
After:
Is there any new method I should be using rather than drawing?
1 Like
Hello! How would I best create an empty EditableMesh? This change seems to have broken my previous strategy of using Instance.new("EditableMesh"), and Iām not seeing any clear new API that would support it. Thank you!
4 Likes
Hello! you can create an empty EditableMesh with new api AssetService:CreateEditableMesh()
local AssetService = game:GetService("AssetService")
local myEditableMesh = AssetService:CreateEditableMesh()
2 Likes
I remember seeing the new object class on twitter. Do instances now inherit object or how does that work?
3 Likes
Apologies for the confusion! I actually did try that and it errored - I should have mentioned it in my original post.
Should I take that to mean that this is an engine error? Or is there a way I can verify my client is updated to the right version? Thank you!
Edit
Iām getting this error which seems to imply that empty meshparts intentionally arenāt supported anymore:
this defeats my attempt at a workaround of just cleaning out a loaded mesh lol
3 Likes