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.
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.
Hi,
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?
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.
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.
Changing the rotation of “Minimap” makes it so that ClipsDescendants doesn’t clip the EditableImages to within its bounding box.
It also creates slight gaps.
Edit: The EditableImages appear to “shake” while moving the minimap (both linearly or by rotating), rotating a couple degrees or shifting around slightly
By the way it must be noticed that setting a rotation to a non-zero angle for an object (exemple: a mere “ImageLabel” with not descendant) makes it shown entirely, even though the parent has ClipsDescendants enabled, and it is not only related to labels having an EditableImage as descendant.
And yeah MintSoapBar, you noticed it, rotating a parent object (such as the “Minimap” Frame in your case) makes that none of its descendants respect the ClipsDescendants propertie. It looks like it just disable it when a rotation is applied (probably for easier calculations).
Regarding the first point of your reply, the UICorner object only apply to the parented object to change its visual, and not to change its box that is used for clipping. So it is expected that the “Minimap” children don’t respect the circular shape.
In your case, because you are already using EditableImage, you could just erase the pixels that are out of your circle by setting their alpha to zero, through the WritePixels method, for example.
Whoops, didn’t notice that was the case for UICorners, I probably assumed it would work because UIStrokes do take it into account 
Right now my current use case is using EditableMesh to make a UV based noise animation on a custom texture based cloud mesh, similar to the ones in games like Genshin Impact and Wuthering Waves(I am 99% sure those clouds are a cylindrical mesh with a shader graphed animated texture). I’m sure this effect would be better achieved with EditableImage, but considering the performance issues those still have for anything other than one time edits, UV edits are my best option here.
I tested with it,it was really cool and i managed to make a little small planet wich i would use for a project(no longer working on it for now,as they dont have collisions)
