Thanks for the bug report. We were able to reproduce and find the cause of this bug. We’ll reply again when the fix makes it into a release.
Great thankyou!
Also I just learned about meshPart.MeshSize! Sorry was unaware of it when I wrote my previous post.
The best update of the year and the worst update of the year at the same time.
Currently I’m working on a small project that requires culling for it to work properly, but performance isn’t exactly the best, even with lots of optimizing.
One request I make is to please make RaycastLocal
parallel safe. This would help a lot with performance on this and many other possible projects.
Hi there! Just curious.
Will we get plugin support for importing images/mesh files and turning them directly into EditableMeshes/EditableImages in the future? (Presumably via StudioService:CreateEditableImageFromFile() or something along the lines of that.)
That would help plugin develop a lot, but if not I might have to nab/create a png parser and then wait for the asset moderation tools to come out.
Thank you!
With the ability to change colors of editable meshes in real-time, could this engine feature be considered on being put to the roadmap also?
I feel like ‘abusing’ editable meshes to get this behavior feels a bit like an unintended usecase, as it’s made for programmers rather than builders.
No. Way. This is insane!!!
The Gamaboi is REAL!!!
Hold up, you are telling me in theory, we could create our own systems for splitting meshparts similar to CSG, now that we can read the vertex data?
The possibilities are endless now.
I am also having issues with this aspect of editablemeshes, as well as Textures don’t appear to update when moving the verts with SetPosition() as seen here:
Nor does it display properly on the back face of doublesided meshparts. As for the Texture not working when the MeshID is blank - setting meshid doesn’t work from scripts, so I have meshpart premade somewhere with a placeholder mesh.
I’d like to be able to use the tiling functions of the texture object without having to manually solve for every vertex’s UV every time I want to resize a ring. If these shortcomings could be fixed, I’d be very appreciative.
you can do this easily with CSG or seperated meshes… nothing new. Same for the image one, just lots of UI frames or colored parts
I am using this API for procedural generation and it’s amazing there are only few problems I found while testing out this beta feature
The first one is the mesh doesn’t render when it’s meshpart isn’t inside of the viewport I am pretty sure this will get sorted out
The second problem I encountered is definitely harder to fix. I added an editable image to a MeshPart and it worked really well, until I tried to customize it with the writePixels method. It takes about 2-3 seconds to make a table that’s needed for a 1k texture which is way to long. I am pretty sure there isn’t a quick fix but my suggestion is instead of passing a table to the to the method you would instead pass a method like it’s passed for table.sort this method would get 2 arguments passed which would be the pixel coordinates(alternatively a Vector2) and the method would return two values a Color3 and a transparency value.
Would it be possible to add the ability change textures/materials per vertex in an editablemesh like you can color and transparency? blending materials together per vertex would be an amazing feature and would open up so many more possibilities with custom terrain and blending parts with terrain/other parts, etc.
luau buffers would probably work better for loading an editableimage instead of a table.
i once tried doing something similar with a bunch of guis, the lag was unbearable and it could only load extremely small images (<256x256px)
Bug report:
Meshes constructed from scratch do not appear to support normal mapping.
(I mean this makes sense we didn’t supply any tangent data…)
Same surface appearance on both of them - just a normal map.
The one on the left is constructed:
local a = mesh:AddVertex(Vector3.new(-0.5,0,-0.5))
local b = mesh:AddVertex(Vector3.new( 0.5,0,-0.5))
local c = mesh:AddVertex(Vector3.new( 0.5,0, 0.5))
local d = mesh:AddVertex(Vector3.new(-0.5,0, 0.5))
mesh:AddTriangle(a,c,b)
mesh:AddTriangle(a,d,c)
mesh:SetVertexNormal(a, Vector3.new(0,1,0))
mesh:SetVertexNormal(b, Vector3.new(0,1,0))
mesh:SetVertexNormal(c, Vector3.new(0,1,0))
mesh:SetVertexNormal(d, Vector3.new(0,1,0))
mesh.Parent = script.Parent```
Are there plans to add more instances to be supported in the future? Editable images would unlock alot of unique opportunities for the following instances:
- Beam.Texture
- ParticleEmitter.Texture
- Trail.Texture
- ClassicShirt.ShirtTemplate
- ClassicPant.PantsTemplate
- ClassicTShirt.Graphic
- Material.ColorMap
- Tool.TextureId
- Sky textures
Would this allow for developers to finally use flipbook effects on meshes in realtime? In a sense that you can manipulate the UV size and position to display a sequence of images?
about time we got this api, glad to see this be a thing
This should only be the case for things that arent free to use in the toolbox. This is too restricted. I had a game idea and this single handedly ruined it. I believe this restriction might be a moderation issue for if a user tries to edit an innoproriate image, they would get in trouble for it too. At least thats all I could imagine its for? I think a workaround for this could be optional moderation for cases where the user isn’t adding to the image, just changing it in ways that cant be turned innopropriate. (For example, stretching the image or erasing parts of it). But also, they could just not edit innopropriate images? I dont know.
If you get a working system done I’m sure many builders would pay you a good amount to use it. Hell I know I would. Keep us updated.