Introducing in-experience Mesh & Image APIs [Studio Beta]

[MightyPart (Mighty)]

Materials (and MaterialVariants) do not work on EditableMesh for some reason.

Also, this may be out of scope for the EditableMesh feature but it would be cool if materials could be applied at the vertex / triangle level.

[Razorter]

I am also running into this issue.

[erqilz]

Yes. Roblox team, when will this come out for games and when will server-to-client replication come out everywhere? To me it seems like the feature (or at least EditableImage, which doesn’t seem to have any bugs really) is mostly okay for release (other than needing server-to-client replication) but has a few small bugs. @monsterjunjun @TheGamer101 @FGmm_r2

[Z_lqify (Kuzey)]

We have used this technology for our global earth game which has got the whole digital copy of earth. Wedges cause a lot of lag so we need an ETA for this so we can also give our communities and estimated release date for the game.

[Dysche]

Awesome! Now we just need the ability to create custom shaders like other major engines, compute shaders included. (Not sure what the technical limitations would be across platforms but I’m sure there’s a way to streamline it somehow?)

[WhiteOut_RBLX (WhiteOut)]

This was a fake image spread by some twitter account.

[kavi_conner (Kavi)]

Yeah, I later found out that the YouTube account behind that post is a fake account.

[ContextLost]

We can’t give a reliable ETA at this stage, but our best guess is likely sometime in the second half of this year. I wish we could be more specific, but there’s still too many variables for us to do that in honesty. It’s obviously crazy, new first-in-class functionality for Roblox, and there’s a lot of axes to the problem.

Our team is working hard to make this available as soon as possible, and it is a high priority project. It’s hard for us to wait too.

Some upcoming technical changes to watch for Soon :

• We’re working on an overhaul of the APIs for normals, UVs, and other vertex attributes.
• We want to enable multiple multiple Parts to share the same EditableImage texture, etc. This will change how they are referenced significantly, probably using new reference properties.

There’s also a number of hard problems we’re working on around permissions, safety, and policy. We’ll share when we can soon. Things are shaping up, but there’s still a lot to do.

Keep an eye on the Creator Roadmap for any official ETA updates.

[eli_isawesome9 (eli)]

When will CreateMeshPartAsync be enabled? I understand if it’s not enabled on the server due to replication and safety issues, but I don’t understand why it can’t be usable on the client?

[gooisbaaaaaaaaa]

It looks like the DataModelMesh Tree isn’t friendly with EditableMesh. When I tried to set EditableMesh inside SpecialMesh, it didn’t work. It still appears as MeshID that DataModelMesh is applying to. I can’t use Instance.new(“MeshPart”) either, because MeshPart Forces Texture To Checkerboard Pattern if MeshPart.MeshId is not set, and MeshPart.MeshId is locked. I can’t use CreateMeshPartAsync, because it’s studio only. There’s no known workaround that is only generated from the script, as it requires pre-initialized MeshPart to get this working. It’s impossible to create EditableMesh from the script without anything referring to MeshPart.

[EatSleepCodeRepeat (escr)]

@ContextLost

We can’t give a reliable ETA at this stage, but our best guess is likely sometime in the second half of this year. I wish we could be more specific, but there’s still too many variables for us to do that in honesty. It’s obviously crazy, new first-in-class functionality for Roblox, and there’s a lot of axes to the problem.

Although this kind of information may seem too ambiguous to be worthy of an announcement, its significant, and I commend the transparency. Thank you!

[ContextLost]

Sadly, we aren’t planning to enable EditableMesh.CreateMeshPartAsync at runtime before we can support replication, so it’ll take a long time. Without replication it would result in mostly broken and buggy usage. I really wanted it to happen sooner, but it would be exceptionally hard to use correctly at this stage.

Locally created parts aren’t something we have ever first-class supported, and it they easily break things like streaming and physics replication that rely on consistency. The only people I know that can do this without it breaking constantly have coincidentally all had source code access at some point. I still want to find a way to make it possible sooner, but don’t hold your breath…

We’re going to focus on making sure you can do any kind of pre-publish visual preview you need to with EditableMesh itself.

We would like to enable support in Studio, similar to CSG where the mesh publishing is deferred until later, like when the place or model is published. We’ll see. It’s lower priority.

[ContextLost]

We’re not planning for EditableMesh to support SpecialMesh or FileMesh. The legacy DataModelMeshes are effectively deprecated. They won’t get any new feature set support, e.g. we intentionally disabled skinning support for them as well, even though it took extra code to disable it.

Only MeshPart and the Wrap* instances will be supported.

[Kurookku (Kurokku)]

Will there be plans to optimize DynamicTextureManager::processPendingRequest I currently have 1000x1000 sized EditableImages inside a few SurfaceAppearence instances in which I store the entire model somewhere on the client. However, any time I clone the model, it appears DynamicTextureManager::processPendingRequest has to be called EVERY time? Will this be the case on release, or will there be optimizations implemented to reduce the processing time taken?

[TheGamer101]

We have some plans to improve the potential for long frame times here. However, 1000x1000-sized EditableImages in SurfaceAppearances still might not be fast enough for real-time effects use cases.

I don’t think we will deduplicate EditableImage textures on the engine side as this would add some overhead, but we will be adding a way to allow multiple parts to share the same EditableImage, which would allow you to avoid cloning EditableImages in this case.

[mhmdsndb3 (Printer)]

How to animate it vertices position?

[Maximum_ADHD]

Are there any plans to support using the buffer datatype for I/O operations on EditableMesh and EditableImage? I think it’d be much more performant to work with buffers instead.

[JESUS5PACHECO (Tvwoman)]

Great, now we need to get a pixel from the client and everything will be complete

[Storm_er]

literally just came here to ask for this lol. i noticed that calls to add geometry and attribs to editablemesh were collectively taking up way too much time

[L3Norm]

@AlasIOof

the whole mesh will be culled when the meshpart itself (which might be smaller than the mesh) leaves the screen

@MrChickenRocket

Also, regarding bounds for culling, is there plans to provide API for this?

@tabby0x

This seems like a issue related to Frustrum culling?

@orangepineappel

the meshes just randomly disappear depending on how i look at them, the terrain is made up of chunks with a editable mesh for each one

@MightyPart

I’ve noticed this as well. This has been an issue for quite a while now.

Thanks for everyone that reported this bug - there was a culling issue in some cases when rendering newly created EditableMesh instances. This should be fixed, but if you’re still seeing it please let us know.