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:
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
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.
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.
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”
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.
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
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.