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
each face only has 3 vertices so the function wouldn’t need a varargs. instead the argument for the first vertex would be required and the rest would be optional:
:SetFaceColors(faceId: number, vert1Id: number, vert2Id: number?, vert3Id: number?)
Also your method of using the same table seems interesting, will definitely benchmark it. thanks.
1 Like
This has been suggested for years, but I’d like to propose it’s something of a more serious issue now.
That issue is mipmap issues. It presents a big problem for using EditableImages as a UV, as the seams will be the blended color.
Here is such an example.
Observe! Those unsightly yellow seams!!
The image on the left is a simple solid color palette on a part. I sample it for the image on the right.
(The mesh UVs are set up to be a square)
The workaround is to outpaint a pixel or two out from the edges, to give it room for mipmapping. But this is extra space and extra work which really should not be necessary. This will happen regardless of how you write the images.
Unrelated, but I am also requesting a way to use EditableMeshes to apply PBR textures i.e. override more than just ColorMap
Vertex positions are locally positioned, not worldspace positioned, you would need to convert the worldspace positions to objectspace
Hi @Ylsid,
Dealing with seams and bleeding is a common problem in texturing which is usually addressed by dilating the colors at the edge of the triangles’ UV. Or you need to adjust your UVs so that the Linear Sampler doesn’t sample from the neighbor yellow pixel.
That issue is mipmap issues
EditableImage doesn’t have mipmaps
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.
Unfortunately, the current implementation of EditableImage isn’t designed or optimized for this use case.
Ah, I suppose I was wrong about mipmapping. I can assure you the sampler isn’t sampling from outside the space- it’s because when I draw the rectangles onto the texture atlas (seen on the left), it creates some sort of antialiasing blending on the edges. If I could turn that off entirely, there wouldn’t be this issue. It’s a little difficult to see from this picture but the edges between the red and yellow (and blue) are blurred into eachother, giving it an off-yellow look on the borders. If it were sampling from the wrong space I figure it would not be a blended color. Setting the alpha mode to overwrite doesn’t resolve this either. Whatever it is, being able to draw onto EditableImages without the antialising-like artifacts would be great.
Is there any hope for NearestNeighbor texture filter for meshes, now that we are getting such a substantial update? If this has already been answered somewhere could someone link me the staff response as to why we still don’t have nearest neighbor interpolation for mesh textures in what’s about to be the beginning of the year 2025? I’m just curious if it’s too performance expensive to implement, or if it’s really that much of a technical hurdle.
4 Likes
Why was GetTriangles and such killed off?
So much of the EditableMeshes changed outta the blue, a project someone was working on that I was testing every now and again is now 100% broken, and the entire backbone has to be rewriten because of stuff such as: “Exception occurred: Unexpected EditableMesh type. Expected UV, received Position”
3 Likes
I’m having an issue where the editable mesh has incorrect normals
In this image I have two meshes
On the left is a MeshPart with the mesh id “rbxassetid://92309772865672”
On the right is a MeshPart with an EditableMesh inside it that was created using AssetService:CreateEditableMeshAsync(“rbxassetid://92309772865672”)
They should look exactly the same but they don’t
7 Likes
This isn’t selfish or stuck up in any way. Either Roblox tries to force optimization and developers find a hacky way around it, or Roblox just gives the freedom and everybody is happy. There is no downside to this. People who don’t know what they are doing end up making games that run terribly regardless.
2 Likes
Thanks for reporting this one - I was going to report it too but you beat me to it.
1 Like
dude this is awesome lol, love the styling and the water physics
2 Likes
good reply
roblox is holding back the advanced devs to compensate for the beginners who can’t properly optimize their games. Chances are the beginner games won’t gain traction anyway, so why lay down these stupid constraints that give the entire engine less freedom overall??
In some cases people genuinely wanna make a pc-only game, but it’ll still end up looking like something from google play because roblox has no faith in us
Hello creators,
We are planning to release some new updates to the EditableMesh and EditableImage APIs to enable the multi-owner references workflow previously mentioned:
These updates are scheduled to go live on Wednesday, October 23 2024 .
Since this update will include a new paradigm for working with EditableMesh / EditableImage data, if you have existing scripts based on this Studio Beta, you will need to migrate your scripts once this update goes live.
More information will be provided in the upcoming dev forum post that will accompany the update but we wanted to give you a bit of advanced notice so you are not surprised when the update goes live.
9 Likes
We just posted a new dev forum post with information about these changes:
This topic will be closed now. Please continue to provide feedback in the above topic instead. Thanks!
1 Like