Personally, I would at least like to be able to use these APIs in an unpublished place without needing ID verification.
I had some unreleased/unpublished projects (local .rbxl files) that I was using these APIs in that I can no longer work on because of this change.
3 Likes
Never mind. I fixed my issue 
The problem is that a small portion of roblox players are from the US and you can only receive your ID from upwards of 18+ years of age in some countries and even way lower than 13 in others, which pretty much ruins the entire point of ID verification. Not to mention some people willnât willingly give their ID information to corporate overlords.
1 Like
Youâve proved once again that americans donât know crap about other countries lmao (me)
To unnecessarily defend myself, I posted that comment before I actually tried verifying myself. The fact they not only request your government-issued id, but also a picture of you holding it is way too much for me. Iâd argue that most kids thatâre vulnerable to anything locked behind robloxâs 13+ restrictions arenât even smart enough to look up a fake id, which is why I do kinda wish weâd go back to the days where everyone was using spongebob driverâs licenses without punishment
It really does feel like roblox is being held back by the large demographic of kids. I hesitate to even support the inclusion of a young audience since these days most kids are playing mobile game slop or pseudo-gambling garbage. But thatâs not really a fair argument, just a rant
where was I going with this? oh yeah, I donât like id verifying and retract that reply
well, not the part about them lifting the permissions change ; )
6 Likes
Will the Content type be added to parts?
If youâre talking about MeshParts, yes
I meant just regular parts. Then we can have proper part to mesh stuff
Seems that thereâs an issue with how the ResetNormal() function works (and just recomputating normals in general)
The object on the left is how I expect the normals to return to when using ResetNormals(), but it seems to get affected by the UVs of the mesh.
(which is also very similar to the previous bug where meshes used to be created with messed up normals like this.)
I think the way that normals are recomputed should be adjusted so itâs more similar to blenderâs âSet from Facesâ functionality, as that doesnât have any influence from the UVs and only from the meshâs verts itself, plus itâs more familiar as a blender user myself 
Since the client has to permit the creation of EditableMeshes based on memory constraints, do EditableMeshes have to be created and modified entirely on the client? Is there no option to create meshes on the server and have them automatically replicate to clients in workspace? Will this ever come in the future?
Im having a lot of trouble with occlusion culling causing several meshes to disappear when in view. Will there be the option in the future to potentially disable culling on certain meshes or some other method to mitigate this?
Iâm having an issue where âDynamicGeometryManagerâ is taking a long time and causing lag
Heres the affected place: Untitled Game - Roblox
Can give edit access if needed
Iâm noticing that something is being recalculated each time an editable mesh is updated
Even if I change just 1 color, this âTranscodeBoxMappedVerticesAndCalculateBâ is run again and it takes a while
Not sure what it is but I canât find a workaround
Setting eMesh:SetNormal() is extremely slow and causes frame freezes
It appears to be because of DynamicGeometryManager :: transcodeVerticesAndCalculateBounds
Why is this so slow? I have ~1000 Vertices sharing the same normal id, and all Iâm doing is
myEditableMesh:SetNormal(normalID, newVector). 135ms is unacceptable.
Same problem with eMesh:SetFaceNormals()
4 Likes
Any update on if ID verification for editable mesh will ever be dropped/loosened to phone number verification or at least be lowered to unpublished experiences? I just wanna make an ocean that doesnât immediately crash my computer thanks bye!
2 Likes
Weâre aware of the lighting behaviors around EditableMeshes and are always looking for ways to improve the developer experience.
Our primary focus with EditableMeshes is to empower in-experience creation and streamline the building process for a wide range of users. While we appreciate the diverse ways developers are utilizing this feature, our current roadmap prioritizes enhancements that align with this core objective.
Weâll continue to evaluate feedback and explore potential improvements to lighting and other aspects of EditableMeshes.
For EditableImages and their drawing methods, I think it would be really cool if we had more ImageCombineType options such as Erase - or even better, the ability to write our own combine types with functions (e.g. an add blending mode formatted something like
function (a,b) return { R = a.R + b.R, G = a.G + b.G, B = a.B + b.B, A = a.A + b.A } end)
Itâd also be great if there was a Transparency/Opacity parameter for :DrawImage() and :DrawImageTransformed(), as the other drawing methods have this!
Thatâs the wrong core objective. Centering a huge feature around a gimmick and limiting it because of said gimmick really sucks. Itâs a cool gimmick, but it shouldnât be the limiting factor.
4 Likes
UhhhâŚ
1 Like
I was trying to put a map of Kerbin onto a quad sphere (a sphere made from a subdivided cube), but there is an issue, which I think is quite apparent. Now, I did figure out that it has to do with how U is assigned to each vertex, and that U = 0 and U = 1 are not on the same vertices. I have no idea whether it is possible to fix this, or if a vertex can even have multiple UV coordinates, but any help would be greatly appreciated.
It doesnât make sense that you need to be ID-verified for something as basic as an image or MESH.
Anyone could create their own image anyway using thousands of GUI objects. I figured out a way to display 20 different pixels per image frame, making this update pointless. Even more so because I need to give them my GOVERNMENT ID.
1 Like