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

[L3Norm]

I’m interested to hear more about the issues you’re running into. What throttling are you seeing? It’s possible that this is a performance issue on our side, so if you have any example place that’s exhibiting the issue, that would also be helpful.

Currently, setting the normals should be working, although there are some details that I should add to the documentation, and as mentioned in the post there are changes coming to that part of the API.

The bottom line with the normals is that if you don’t set them, the default is the geometric normal. If you do set them, that normal will be used. However, if you move nearby vertex positions or add/remove triangles, the normals may be changed. In general the most reliable approach would be to set the normals after you’re done moving verts or changing the topology in the area.

Here’s an example snippet that shows the behavior:

local emesh = Instance.new("EditableMesh")
local v1 = emesh:AddVertex(Vector3.new(0,0,0))
local v2 = emesh:AddVertex(Vector3.new(1,0,0))
local v3 = emesh:AddVertex(Vector3.new(0,1,0))
local t = emesh:AddTriangle(v1, v2, v3)
local initialNormal = emesh:GetVertexNormal(v1)
local newNormal = Vector3.new(.5,.5,0)
emesh:SetVertexNormal(v1, newNormal)
local afterSet = emesh:GetVertexNormal(v1)
emesh:SetPosition(v1, Vector3.new(0,0,1))
local afterMove = emesh:GetVertexNormal(v1)
print(initialNormal)
print(newNormal)
print(afterSet)
print(afterMove)

and outputs:

0, 0, 1
0.5, 0.5, 0
0.5, 0.5, 0
0.40824830532073975, 0.14942926168441772, -0.5576775670051575

Although like I said, there will be some changes to the API, as mentioned in the post.

Finally, thanks for the feedback about the desire to edit the collision geometry and write to meshes in parallel.

[CookieOdi]

I assume this does not work with ScreenGuis? I have tired but it doesn’t work but the post does not say anything about it.

[N3rmis (Nermis)]

Love this update so much!
instantly tried porting some glsl

Although i’d complain that the math as a whole is still very slow
but expecting updates on that, thanks!!

[L3Norm]

Here’s a very simple example that shows GetAdjacentTriangles working:

local emesh = Instance.new("EditableMesh")
local v1 = emesh:AddVertex(Vector3.new(0,0,0))
local v2 = emesh:AddVertex(Vector3.new(1,0,0))
local v3 = emesh:AddVertex(Vector3.new(0,1,0))
local v4 = emesh:AddVertex(Vector3.new(1,1,0))
local t1 = emesh:AddTriangle(v1, v2, v3)
local t2 = emesh:AddTriangle(v3, v2, v4)

local t1adj = emesh:GetAdjacentTriangles(t1)
local t2adj = emesh:GetAdjacentTriangles(t2)

print(t1adj)
print(t2adj)

[kylepo99]

I’m also experiencing the same issue as @Collect1ve. Any attempt to use GetAdjacentTriangles just returns an array of 0’s. GetAdjacentVertices and all other methods work fine.

Running that provided code gives an output of

[savio14562 (savio14563)]

Image labels have a property call Resample Mode. It has an option for Nearest or something like that.

[cyn0x8 (cyn)]

I’m doing something similar and having the same problem, likely because everything is done on CPU and not GPU (so I just resorted to pre-rendering frames).
I think Roblox would really benefit from a shader node system! I know about the zeuxcg post concerning the problems with adding shaders, but this post is 7 years old… Computers have become much faster and Roblox has grown significantly since then, maybe now with the resources to tackle the challenges implementing something like this?

[EgoMoose]

I was playing around w/ this and I noticed a few issues I didn’t see mentioned on the main post.

The first is that materials seem to become a blurry mess on editable meshes. In the screenshot below I took a picture of two mesh parts that haven’t had any modifications made on them with and without an editable mesh:

The second is that texture instances don’t seem to respect the UV mapping set in the editable mesh. In the below images the top surface has a texture instance on it. You can see that the UV is being adjusted by looking at the sides of the block which has a stripes on it, however, the texture instance is not.

[N3rmis (Nermis)]

I mean yeah it is probably one of the reason why its slow but i think you underrate cpu
I believe that roblox caps cpu alot because no one wants their pc burnt by a troll dev
and other engines actually run 2d cpu shaders waaay faster than roblox so yeah the cap is real

[dogwarrior24 (dog)]

External Media

Working on a custom foliage system similar to the one that was demoed a long time ago for hack week but got scrapped. There are some problems I’m running into with performance, and I’m left with a few suggestions for what to add in the future:

• Enable setting vertex positions in parallel. Not sure how this could be done safely, maybe only allow scripts to edit meshes made under the same thread? Also not sure how much of a gain this would really bring, it depends on where the bottleneck is.
• Add a function to move many vertexes at once, similar to the workspace:BulkMoveTo() function but for vertexes.
• Add the ability to apply a single EditableMesh to multiple meshes at once, basically instancing. I can think of many applications this could help speed up substantially, such as foliage and ocean systems.

For reference, the amount of grass in the video above is already using 3ms, which is around the frame time I hoped an entire game level would have, with a proper LOD system in place of course.

[MrChickenRocket]

Hello! A few questions for the devs:

What are these properties for?

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

It seems meshs internally have a “Scale” that is not exposed anywhere?

How are you expected to create a mesh from scratch and have it cull correctly - it seems to me the only way currently is to size the host mesh to the size of the mesh and use normalized position data?

[Storm_er]

I later found out that this “throttling” was not throttling, but instead a precision issue caused by math.noise. I guess the numbers os.clock spits out are too big for math.noise to give precise results. It made it seem exactly as if my scrolling noise mesh were updating infrequently, it was an easy fix ofc. My bad lol.

I messed with it a bit more, and it looks like I have to set my normals after tris are added, because like you said, adding tris will overwrite existing normals. This is why it seemed my normals weren’t being updated. This seems a bit awkward and I wonder if it might become an issue in some fringe scenarios. What if I want to edit geometry without affecting surrounding normals? Wouldn’t I have to go back and set them back? Something along the lines of vertex smoothing groups might work better. I also wonder, would this system add any significant overhead in cases where custom normals are heavily used?

[Storm_er]

We still need a good way to texture this without making each type of block into its own material and separate mesh. The extra draw calls aren’t too great for lower-end devices, and I’m gonna assume making all the extra mesh instances ought to add a decent bit of performance cost. Using a texture atlas to circumvent this presents some issues for a couple reasons. Roblox’s lack of nearest-neighbor filtering (for pixel art), the 1024 resolution limit, and the inability to edit mipmaps. I’d love to see this stuff addressed, and maybe they can even add texture arrays, which would allow us to use textured greedy meshing with a single draw call.

Lighting is also a huge concern. I guess you could do lighting using ambient light + vertex colors to achieve vertex lighting like minecraft has, but all other options are full of issues. Maybe once roblox improves their voxel lighting systems and their light probes we can get some decent results. Even after all that, we have to hope that creating custom collisions and generating a meshpart (required for roblox’s voxel lighting) will be fast enough.

[SamSwifthoof]

Yes, I reuse vertices if they share the same material and that is the reason why I use solid colors on the texture (with some bleed since I was sloppy with the UV placements).

Tried to come up with a way to unwrap the UV but don’t think it’s possible, I would guess that games such as Minecraft disregard the UV data for blocks and use a shader to box project since that would have been a much easier and performant solution.

[Collect1ve]

local AssetService = game:GetService("AssetService")

local newMesh = AssetService:CreateEditableMeshFromPartAsync(script.Parent)

newMesh.Parent = script.Parent
local VertexTest = newMesh:GetVertices()

for i, v in VertexTest do
	local LocalPosition = script.Parent.CFrame:ToObjectSpace(CFrame.new(newMesh:GetPosition(v))).Position
	local WorldPosition = script.Parent.CFrame:ToWorldSpace(CFrame.new(newMesh:GetPosition(v))).Position

	print('Local: ' .. LocalPosition)
	print('World: ' .. WorldPosition)
end

Should work

[CeaselessQuokka]

When loading certain meshes, it will result in heavy RAM usage and then a crash a bit after:

Two assets that seem to cause this issue: 13336080645 and 13185713295

I only have the EditableMesh beta enabled, and all plugins have been disabled.

[AlasIOof]

Emphasizing something mentioned earlier in the thread. Textures are not showing on EditableMesh’s Meshpart unless you set the MeshId of the Meshpart (which should be unnecessary since you won’t be using that meshid anyways). Seems like a bug.

[Proville6]

There should be functions for adding quads and polygons to editablemeshes

[kalrnlo (witchiest)]

Can a method be added to EditableImage for drawing text? This would be great for making static signs, and would allow not having to use SurfaceGuis for a static image.

[hello42]

Will there be support for a shoe-in kind of “UV masking?” There’s a very high value proposition here for being able to mask a contrast (brightness) texture on top of a color texture