Yes, EditableImages and EditableMeshes need to be on the client to be displayed, but there is currently no replication.
EditableImage and EditableMesh do not persist / are fully cleaned up when a game is closed.
Yes, EditableImages and EditableMeshes need to be on the client to be displayed, but there is currently no replication.
EditableImage and EditableMesh do not persist / are fully cleaned up when a game is closed.
Speaking of ViewportFrames, will we ever be able to use their contents as something akin to an editable image? IE: Content.fromViewport()
No ETA yet, this is something we want to get to but dealing with PBR in an elegant way will take a bit of time and we want to get it right before enabling this.
We agree! This is being worked on right now for Studio plugins so keep an eye out for it. Unfortunately, no specific ETA to share yet.
Permissions are a complicated beast due to possible asset misuse. We are starting with something restrictive now so it will allow us to open things up in the future as we get more feedback. Thanks for letting us know your use case and we will keep these in mind as we continue addressing feedback.
You should be able to eventually use these APIs on client and server. Today, since this is still in Studio Beta, you cannot publish experiences with this yet. I added a bit more to an FAQ section in the original post.
Yes, I added a bit more info in the FAQ section above.
For clarification, does this also mean editable meshes/images created server side (NOT created by a user or users, but rather a server script not related to user input or interaction) wonāt automatically replicated, or is this strictly client to client(s)?
An Object class with no property an Instance have? Has my organized world come to an end? Will I become a mad scientist determined to find everything related to this new thing? Sure am!
Correctā¦
editable meshes/images created server side (NOT created by a user or users, but rather a server script not related to user input or interaction)
will NOT automatically replicate to clients when these APIs are released due to safety reasons.
We are planning to open things up slowly and it is likely that Server ā Client replication will be one of the first things that opens up since it has a slightly lower risk profile.
I have a feeling that this Object class is going to be insanely powerful in future stuff, like maybeā¦ stylesheets? Or shared UI effects?
Whatever it is, Iām definitely looking forward to it canāt wait for the day that my UI pains are long gone!
Personally I expected AssetId to accept an IDās for editable*'s, but turns out the entire thing is being changed.
How long will this transition to InstanceClass.*Content
go for?
Though on the other hand, it is good to know that Editables arenāt forgotten yet as a whole and are still being actively developed. Canāt wait to make potential projects with this.
Content.fromCanvasGroup()
would be nice too! It can be a way to optimize multiple canvas groups showing the exact same thing. It would also let us modify them with EditableImages!
Are there any plans for Precise
collision?
I have already seen many people create custom terrain systems (& other similar things) and many had to go back to the old method of just creating tons of wedge parts to create custom triangle collision to match the mesh geometry. It kinda ruins the point of editable mesh (to a degree) because then we still get the performance drop from this unoptimized wedge method.
It has already been asked for many times in the past, and now seems like the perfect time to add such a thing.
These API changes are awesome, I hope that this Content datatype makes its way into the API for viewport frames or a similar feature that does the same thing so that we can reuse the rendered result across multiple pieces of UI.
Catastrophic BOOO for this, thatās a 5+ year āpromiseā. We can already draw anything we want using an array of frames as pixels. We can already slap together spheres and other primitives to make hi-fi models of anything we want. Moderate the game after the offense has been done, not preemptively. Donāt destroy wickedly powerful API before legitimate developers can use it to make something amazing. This restriction outright kills 90% of the most interesting use cases for this API. Every single procedural game with generative content would utilize replication.
You may be underestimating the power of just replicating these changes manually. But also its not a very good idea to do mesh work on the server to replicate to all the clients anyway, its much better to just send a signal to the client(s) to figure out that work on their own. If you really want to replicate from the server, you can very much just make that manually.
Is your question about setting CollisionFidelity
for EditableMesh
? If so, when you convert an EditableMesh
into a MeshPart
using AssetService:CreateMeshPartAsync()
you have the option to pass in a specific CollisionFidelity
option including Precise
Note:
EditableMesh:CreateMeshPartAsync
will be removed before public release in favor of AssetService:CreateMeshPartAsync
, which will be changed to take Content
as its first argument, optimized, and made publicly available in the public release.
If your question is more generically about improvements to Precise
collision fidelity itself, we are thinking about ways to overhaul collision fidelity calculations as whole and thinking about ways to properly address some of the issues creators are facing today (eg. doors that you cannot pass through, properly balancing precise vs. other more performant options etc.) Those improvements will be orthogonal to EditableMesh
but when they arrive, we will make sure to update CreateMeshPartAsync
as well to leverage any improvements.
What about fluidfidelity? Im planning on using editablemeshes in my flight simulator
I was just questioning if we get more precise collision for editable meshes (considering terrain systems, etc.) over just the current CollisionFidelity
options. (I got my answer for this, though.)
This would require building a complex encoding format for something that may be as in-depth as allowing players to resculpt prefab creature body meshes (e.g. fatten, shrink, stretch, and bend flesh around a spine alike Spore). These controls if programmed properly prevent the creation of inappropriate shapes but are very highly dimensioned and are very difficult to replicate, especially when combined with the rest of the data that could be associated with such a use case.
We shouldnāt have to make hacky solutions to work around the engine babysitting us, and I certainly do not want to have to wait half a decade for Roblox to figure out how theyāre going to moderate this. Regardless of what they do, theyāre going to have to execute the game to figure out if bad things are happening or not. This means that people making inappropriate buildings would be caught just the same as people doing the same with editables. I would only have hope if their plan is to run output through an AI on the fly.
I think you misunderstood what I was replying about
I was only replying about the replication and how it isnāt as much of an issue as youāre making it seem (though I understand the annoyance)
Iām not really sure how I feel about the moderation but thatās not relevant to me atm
is this a bug? im trying to link the editmesh to the mesh so it can respond to future edits
I think Iām lost.
You canāt publish editable images until later, so I canāt use it for any in experience creation like drawing unless I want it to be unmoderated.
You canāt replicate editable images, so I canāt use it for any live drawing things unless I want to do all that replication myself, unmoderated.
And now you canāt use images you havenāt uploaded, so I canāt use it for live in experience creation effects for things like removing backgrounds, changing colors, photo editing, etc.
Soā¦what can I use it forā¦? Iām totally lost on what the use cases for EditableImage are at this point or what the product will be when itās released.
Just starting with the bare essentials. Once the Content
property type is battle tested in this first wave weāll start more aggressively converting all of them.