I can provide some reasoning behind the EditableMesh changes. There are 2 categories of changes in EditableMesh with this update:
Split attributes on a vertex
Methods using triangles → faces
The reason for the change in #1 is that there are many mesh editing scenarios where it’s very difficult to do the right thing if you only have 1 set of attributes on a vertex. In the example at the top of this post, a sharp cube uses a lot more vertices and normals.
But more importantly, always having to duplicate vertices makes mesh editing operations difficult or impossible to do correctly. For example, if you want to move one of the cube corners, then you need to move 3 vertices at the same time, or else the closed cube will open up. We also ran into cases where editing some smooth meshes would cause severe visual artifacts because a vertex had been duplicated due to a UV or other seam, which made recomputing the normal impossible.
We’ve heard several requests to make more convenient and more performant methods for editing attributes on vertices, which is something we’re working on. But we wanted to get the essential functionality for split attributes out earlier, so any breaking API changes happen during the studio beta. We’ve also optimized many of these methods from their initial (unreleased) implementation.
The reason for the change in #2 is that at some point it would be very useful for mesh editing workflows if EditableMesh supported triangles, quads, and n-gons. This is not something we have implemented for the first release, but we’re making this change so that the API is easier to use when we have those implemented.
It seems to me that when getting the UVs of a mesh and assigning them per vert (Via now saving GetUVs and iterating through the table with a for loop) They aren’t being fully overwritten?
Converting my previous code that required getting the normals per-vert and assigning the UV’s to each individual vert was heavily impacted by this, so I’m hoping that there is just a simple solution that I missed.
Hi Bravo, I’m not sure I’m understanding the issue you’re seeing fully. Could you explain a bit more about what behavior you’re seeing vs. what you’d expect to see?
I’m unsure if it’s helpful, but I made a small sample rbxl with animated UVs.
I was kinda disappointed to not see ResampleMode added to EditableImages, but I will say that proper normals is something I was missing and was one feature that was holding me back from optimizing my voxel game. It’s also a shame that this feature is still not out for client beta, especially since it has been in studio beta for well over a year now
Any possibility of mesh & image generic assets to link to mesh / image inputs? Unlocking instancing with mesh and using textures more broadly across the engine. Would love to generate normal maps without needing to export / upload them. It would also enable us to generate our own skyboxes, again without having to export then upload.
Influencing SurfaceAppearance colormaps with vertex color & alpha would also be very useful
Is there any plan to add a method like :GetVertexAtPosition ? Right now id either have to store all the vertices in a dictionary (i imagine that would take up a lot of memory, doesnt the editable mesh do that internally already?) Or I’d have to do some expensive operation like: FindClosestVertex() > GetPosition() to make sure its nearby
Also please add a ResampleMode property, or else im not too sure how i could continue my voxel game.
Can you please get SERVER TO CLIENT replication working? There’s no reason to moderate that beyond basic server moderation that already exists. I get that you don’t necessarily want to allow client meshes to replicate to servers and then to other clients. But servers can already create arbitrary meshes on clients (see EgoMoose). And we can now do it by sending vertex data and using EditableMesh off a client listener. So there’s no valid reason that EditableMeshes don’t just get replicated to all clients FROM the server as is.
Its a good change but could be better. Like the improvements but i would love to have is the vertex IDs match with their corresponding face, normal, uv and color id for simplicity. It would be also nice if its 0 based indexing instead of the current indexing.
Overall i find similarities to OpenGL API which can be very difficult to grasp but this improves performance and “creativity”
Am I missing something or is the biggest missing piece of the Editable Mesh system the inability to turn can collide/collisions and physics on? I want to generate structures with them but I can’t.
Please tell me if I am missing something or if anyone else agrees. Thanks
The current behavior from what I’m seeing is that, whenever I get the UVs of a pre-existing mesh (just to get the UV’s associated ID), When I set the UV, It seems to inherit the UV’s that the pre-existing mesh had with it.
This is the original video of how it was working back in February, which is the intended behavior:
And this is the effect now
I’m worried that there’s not gonna be any support for editing individual verts in the future without having to get the associated face, or that it’s going to be meant for only making new meshes and not altering pre-existing ones.
About 3 months ago, I made a module called “Mesh4D” that slices 4D shapes into 3D shapes using editable mesh. I recently realized that the module works differently than before and found out that there was an update 5 days ago…
Is this a bug? Why are weird shadows forming? (Doublesided property is on)
Is there any chance we’ll be seeing the Editable Image instance override textures for Particle Emitters or Beams? I would really enjoy working on a plugin tool to edit textures and seeing the changes live without having to use AssetService / saving the asset as a new ID every time I wanna see how it looks
This is a very very simple prototype I made in a few minutes just to mess with the API but if Particle Emitters and Beams get support and we’re also provided with a simpler way to export Editable Images I’d go full effort to make a plugin to quickly edit textures with various tools that might eliminate the need to go to external programs for smaller adjustments
Correct, the only methods to remove topology is RemoveFace (which removes the given face) and RemoveUnused (which removes all vertices, normals, colors, and uvs that don’t appear in any face). It sounds like it would be useful to remove a single vertex?
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?
There’s no current plan to allow editing tangents and bitangents, but we are currently working on recomputing those automatically so normal maps work (as long as UVs are specified)
At the lowest levels, there is now another level of indirection. Previously the attributes were directly stored on the vertex. Now the face stores a list of vertices, along with attribute ids for each vertex. The most common case is to have the same attribute ids for all faces on a given vertex, which is how we create attributes with AddTriangle. We’re looking at convenience methods to get/set attributes on a vertex, since that is such a common use case, but wanted to get the essential API out first.
If you can privately DM me an rbxl file, I will take a look. This UV cycling should be possible to accomplish with the new API.
That does look like a bug. The automatic normals are being calculated with a new code path, so it’s possible that that code needs some fixes. If it’s possible for you to send a repro file, that would be much appreciated.
then maybe put your marketing schemes aside and allow for pc-only games to have less restrictions?
because there’re definitely teams that only want studio for its pc use. I personally can’t see myself adding mobile compatibility to 50% of my projects because they’re just suited for pc. That’s like trying to get ultrakill on mobile
