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

What I would like to achieve is tiling (both organically and inorganically) a texture across select regions of an EditableMesh.

Whilst Using a texture atlas and setting uv coords can create inorganically tiled textures it can’t be used to organically tile a texture. Also loading in a big texture atlas may not be the most efficient use of memory in cases where only a few of the textures are currently being used.

I wanted to ask you. Will it be possible to access the normals from the back of the model? That is, if the reverse side display mode is enabled in the grid. This is especially useful for creating plants and other visual techniques that require uniform shading of both sides of the grid. To put it mildly, is it possible to change the normals of the back of the model so that it is shaded in the same way as the front? And it would look beautiful. This is one of the many examples of using the normal setting of the back side of the model.

1 Like

I’ve managed to make Parallax mapping using Editable Meshes, and found quite a good degree of success. This uses imagelabels and EditableMesh to create the illusion of 3D space on a 2D plane.

Though I tried using editable Images, since there isn’t a way to easily deform the images I wasn’t able to make the rotated planes as accurate as possible.


why do you wanna talk about this? It’s just grass, everyone can make custom grass.

Anything new regarding the publication of in-studio generated editable mesh ? It would be increadibly usefull for mesh adjustement when importing meshes to roblox studio and adjusting them to the map.
Is such an update planned ? And what about the in-game update of the collision cage of an editable mesh ?

Yes, but the physics just are impossible to achieve, I need to iterate over hundreds of grasses and rotate each one, the problem is not the mathematics… it’s that I am iterating over hundreds of grasses, So I need another method of moving the grasses without iterating on each one of them

If we don’t have the possibility to run the code from the GPU, this is still unusable… it’s a big job but no one wants to slow down their game for a few decorations.

Oh, i just used chunking and frustum culled the grass. So if a grass chunk is not visible then i just don’t upadate it. Also i only check for chunks in a certain distance, so if it is too far then i don’t update it. One thing i didn’t do is throttle the grass in the distance, so you can try to make the distant grass update in lower FPS. And tho i am not sure about this, but probably it could run faster if it wasn’t made in EditableMesh, but MeshParts, unless they release Bulk functions for EditableMesh. Not sure about this tho.

Currently, changes made to EditableMeshes inside ViewportFrames do not update the rendered mesh. Is this a known issue and are there any plans for this to be fixed?

1 Like

Thanks for reporting this. We are looking into a fix for this. Out of curiosity, what is the use case you are shooting for that requires ViewportFrame support?

I know I’m not the one being asked, but I have a sticker system using editable meshes and I wanted to allow people to put stickers on weapons inside of a UI (ViewportFrame). The sticker mesh would need to be updated as the user moves/drags it around, so up to every frame. This is a use-case I have for this.

1 Like

One of the best ideas EVER! Please do more updates like this one!!!

Will editable meshes eventually be compatible with workspace:Raycast(), Shapecast, blockcast, and spherecast? It’s sometimes a little tedious to have to use RaycastLocal for a specific mesh when you have many to go through.

RaycastLocal is precise with the mesh geometry, while the Workspace’s Raycast (and shapecasts) use the mesh’s collision geometry. The only reason this doesnt work with editablemeshes is because they don’t have their own collision geometry yet. Once they do, Workspace’s raycast will work.