One thing I’ve noticed in the latest update is that when you start getting long triangles, you can develop a strange specular aspect to the colors. This is using color blending (I’m blending from white on the bottom to yellow at the top). The same algorithm doesn’t produce the metallic sheen with shorter triangles. And it doesn’t anyways do it.
No current plan to add this. What is your use case for this? Would you expect it to be exactly equal, or equal to within some tolerance?
I’m making a voxel game, and when implementing a :DeleteBlock function, id have to find the vertices that compose that block. The easiest would be a GetVertexAtPosition function. alternatively i would have to store all the vertices used. This would likely add overhead, as im guessing internally editable meshes already have a correlation between vertex id and position?
1 Like
Okay unrelated on some level but while we are already talking about low end android devices, why are you still supporting them? 2GB is insanely limited, alongside you STILL SUPPORTING OpenGL ES 2.0 on android after it has been said that it has been deprecated, yet its still functional in the engine and is STILL holding you back from progressing at all on graphical features.
I talked to a rendering engineer at RDC and they clearly told me that the majority of features are held back by this exact graphics API. Which confused me because I thought you had deprecated it? Turns out you didn’t and its still in the engine for some reason?
It being still in the engine has had so many feature requests left ignored and scrapped:
- Deferred Decals (scrapped because of GL ES 2.0 missing a critical feature that was present in GL ES 3)
- Emission Maps (Apparently this is because of texture compression, which i don’t understand because ECT1, ECT2 and DXT5 all have 0 difference if you add 1 extra channel to a image that is currently unused??)
- More Post Processing Effects
Its literally 17 years old, please just let go, there has to be a certain point where you just can’t continue supporting these sort of users, its actively hurting the creativity and freedom of the developers who want to make something more than just a simple Obby game.
I’m not asking for Unreal Engine 5 level of fidelity, no. Instead I really just want to have more control over what the engine is doing instead of having nearly 0 control over things and I think a lot of developers here agree with me.
Hey tabby0x. I updated the other thread https://devforum.roblox.com/t/roblox-needs-to-drop-support-for-opengl-es-20-and-require-opengl-es-30-as-the-minimum-for-mobile/3167041
but to clarify, OpenGL ES 2.0 is not the reason these features are held back.
Many newer but cheaper phones support modern graphics APIs but still have limited memory (among other limitations).
3 Likes
It is possible to create triangles with Vector3s that are made up of nan values. Doing this causes issues with all meshes that are rendered on screen, including unrelated MeshParts.
local nanVector = Vector3.new(0/0, 0/0, 0/0) -- Vector made up of NaN values.
local part = Instance.new("MeshPart", workspace) -- New mesh part.
local mesh = Instance.new("EditableMesh", part) -- EditableMesh.
mesh:AddTriangle(
mesh:AddVertex(nanVector), -- X
mesh:AddVertex(nanVector), -- Y
mesh:AddVertex(nanVector) -- Z
)
in my use case, the remove face works fine as a replacement, but I do think we should still have the option to remove a single vertex
Shiny triangles seems to happen whenever the triangles get narrow. Here’s an example of edge fans around some polygons. When the triangles are wide, like say a plain hexagon, there’s no shiny. When they get narrower, you get randomly shiny triangles. This is why colors for all the vertices set to Color3.new(1,1,1).
1 Like
Sorry:
This is WITH colors for all the vertices set to Color3.new(1,1,1)
why did the functions need to changed like this? being unable to properly clear vertexes made my voxel renderer create some artifacts when destroying blocks by attaching vertexes with neighboring blocks and causes random crashes after a while (Yes I do use the new function that clears “unused vertexes and triangles”)
the code became even more bloated and redundant and the documentation is very subpar and doesn’t explain most of these new functions properly
1 Like
Hey. There is issue with mesh position.
local part=script.Parent
local mesh=Instance.new('EditableMesh')
mesh.Parent=part
local v1=mesh:AddVertex(part.v1.Position)
local v2=mesh:AddVertex(part.v2.Position)
local v3=mesh:AddVertex(part.v3.Position)
mesh:AddTriangle(v1,v2,v3)
part.Parent=workspace
v1,v2,v3 are red blocks but it looks like it doesn’t works correctly
Has anyone else been getting this error? It started happening to me perhaps a week before this post was made. None of my EditableMeshes work any more. I acknowledge in OP post it mentions code may need to be updated, but I’m not entirely sure what I’m doing wrong ^^’
from code
I’ll update the error message so that it’s clearer. It should say that it was expecting a vertex id, but got an unknown type of id.
What’s happening here is that the code is using the index into the vertices array instead of the vertex ids.
Try:
for _,vertID in mesh:GetVertices() do
Previously the vertex ids were usually (but not always!) 1,2,3,4, etc. so you could often use the index into the array as the vertex id. However, if you ever deleted a vertex, than that would no longer work. The ids now contain information about what type they are, to help catch those issues earlier.
2 Likes
Thanks for the fast response, I was feeling it was something to do with that 
I think I’m experiencing the same problem.
In the process of re-writing my water VFX code and the API update led to it misfunctioning in a pretty funny way:
No longer water, more like elephant’s toothpaste reaction
13 Likes
Oh, I missed your earlier post because I thought it was about shadows. Yeah that’s the same issue! Some narrow triangles become high specular for some reason. It makes the API pretty unusable for programmatic meshes. I was hoping it was going to be fixed by removing AddColor… but if you’re using the old API, then it looks like it’s just a problem even without vertex colors being set.
It would be awesome if a DrawTriangle/DrawPolygon API will be added in the future for EditableImages, this would allow us to possibly make semi-fast custom renderers.
2 Likes
I found a workaround for the shiny narrow triangle issue. There’s an (admittedly weird) pattern for assigning autocomputed normals to the face vertices.
local faceId = self.editableMesh:AddTriangle(v1, v2, v3)
local normal = self.editableMesh:AddNormal()
self.editableMesh:SetFaceNormals(faceId, {normal, normal, normal})
Note, I’m not setting the normal to be anything. I’m using the unassigned value. If you do this, the shiny triangles will all go away. This is what you’d think would be the default behavior, but it’s apparently not. And… I could be wrong but somehow assigning the normals makes things render… faster? It feels like it, but it’s hard to say.
1 Like
So EditableMesh:SetVertexColor() has been disabled. Is there a new way to change the colour of the vertex or can you only use EditableMesh:SetFaceColors()?
1 Like
In luau, yeah this is pretty bad.
It’s highly suggested that you reuse a table and clear it using table.clear; this will be faster than varargs (at least I’m pretty sure it will because internally, arrays hold the array’s length).
2 Likes