They only care because their stocks are at risk. They never bothered to implement such moderation on any other previous feature which could be used in similar manners until now. They never really bothered to implement any real parental control systems because they never really had any direct reason to do so until now. Roblox never cared, they only do now because ultimately the parents (and other third parties on the side of parents) can put a dent in their stock price.
You’re not wrong but the thing is that no bad actors would really try pushing this sort of feature to its limits. Why? They already got better methods of doing so such as bypassed decals. Most people looking to push this sort of crap on children often also lack the skill and patience required to even get editable images/meshes to display inappropriate content. There’s already quite a few features which could be used to bypass moderation however 99% of the time its simply either bypassed decals, crude builds made out of parts, bypassed audio and bypassed shirts with decals. Yes it’s true that editable images alone technically have power on the level of actual images however that power comes with 50 more technicalities which most of these people would find as “too hard to use” or “not efficient enough” or whatever else.
As for random people just drawing genitals in art games with those features, It happens. Should it be happening? Nah, but ultimately trying to lock down this useful feature so much just for the fear of that happening is insane. But of course, we can’t have the spooky parents taking a bite out of the roblox stocks again. I’m sure that must be a more traumatic experience for the higher ups at roblox than it is for the children seeing said drawings.
Also another thing is that roblox themselves keep forcing whatever new changes on us, keep locking down X Y and Z and do whatever other stuff all for the sake of moderation yet they also magically claim how AI moderation will be the future or whatever. Don’t forget the fact that one of the BIGGEST feature on the site is getting next to 0 moderation and everything is A-OK, all while they tell us how scary it would be to have the possibility of someone crudely drawing a bad thing in a random art game using editable images so therefore they have to lock down everything.
As to getting back for your first point, It’s kinda crazy how we now have to assume that people who want freedom are also the same people who want to abuse said freedoms. Ultimately, at least for me, this isn’t just about freedom. This about BOTH freedom and the general insanity of the restrictions. What do you mean the complicated engine limited image and mesh api’s get to be forcefully locked down while catalog creators get to upload straight up pornographic material? Well i guess their excuse is that it’s “technically” not porn because no ones naked.
I do apologize for this longer rant. But that’s just how things are right now.
YOOOO!!
I’ve been waiting for this for a long time!
Quite a while ago I used the In-Experience Mesh & Image API to create a FFT (Phillips spectrum) ocean, now I can see it in it’s full glory!
Everyone I know was literally so hyped for custom terrain whether it be voxel or smooth with editablemesh, and now we got hit with a very low editablemesh limit on client, 8, and worse, a dynamic one, making it completely useless for custom terrain. Is there any possibility that the limit will be removed or at least be able to be determined manually to set number?
We changed UGCValidation to use the Editable* APIs internally in preparation for some future work. Let me look into this and potentially disable this change.
I’m really glad that this feature is near release! But just for clarification, Skinned Editable-meshes will work with animations like how normal skinned meshes do correct?
I’m experimenting with generating voxel meshes using EditableMeshes, but I’ve encountered significant performance issues when using Precise Convex Decomposition for collision fidelity:
Rendering only the outer faces of a voxel mesh up to a size of 14×14×5 takes 5–8 seconds to instantiate a MeshPart.
However, increasing the size to 15×15×5 causes the instantiation time to skyrocket to nearly a full minute!
This is very surprising, as the mesh I’m instantiating is very simple (as you can see in the video below).
Here’s the code I’m using to measure instantiation time:
local t = os.clock()
worldMeshPart = AssetService:CreateMeshPartAsync(Content.fromObject(eMesh), {CollisionFidelity = Enum.CollisionFidelity.PreciseConvexDecomposition})
print(os.clock()-t)
Also, when enabling Render Collision Fidelity in Roblox Studio’s viewport settings, the collision decomposition for the EditableMesh doesn’t appear to display at all. This occurs regardless of the collision fidelity setting (PreciseConvex, Default, Hull, andBox).
Here you can see a video of the 15×15×5 mesh with precise convex decomposition, and a demonstration of the collision fidelity display not working. The debug output shown in the video also shows the output of the code snippet provided above.
Is this performance behavior expected for Precise Convex Decomposition? I’ve tested other, more complex meshes from the toolbox with collision fidelity changes to Precise Convex Decomposition, and they took less than 1 second to convert in Studio.
Are there any known fixes for EditableMeshes that could address this? Is this extreme delay a bug?
Is there any way to make the Render Collision Fidelity setting display the decomposition for this EditableMesh?
The 13+ ID verification requirement to use the API only applies to the owner / group owner of the experience, not to individual users in the experience.
The 13+ age requirement for freeform creation is a separate content guidelines / age recommendations policy. That one doesn’t depend on which technology you use, just the experience that you build with it. It applies to rotated Frame-based drawing tools as well as EditableImage.
If you are using Editable* for procedural generation that is not freeform user-driven creation, only you, the developer, would need to be ID verified. Usage of Editable* does not automatically make your experience 13+ only.
Why though? I have pointed out already that this efforts are completely useless, as developers on roblox can already make enough with existing features, but with degraded performance… (look my message somewhere above)
Maybe I missed something important that you guys know about that?
It seems that every editableMesh/Image update that gets released, the worse it gets. When editable meshes and images had first released, they were really easy to use, and yeah, the new Api features that have been added are cool and useful, but it seems like the process has been extremely overcomplicated now. I used to be making tons of stuff with editable meshes and images but now I can’t even figure out how to get a live render of a plane.
and all of these “security features” are just stupid. how is preventing the use of other people’s meshes going to stop anything?? it’s not. if someone wanted to do something bad with meshes, chances are they’re going to any of the thousands of sites or apps to get or make models. and the same thing can be said towards images.
and the fact that you guys are going to lock an Api behind 13+ and ID verified because your moderation sucks is beyond sad.
leave it to roblox to ruin what could’ve been the best update to release.
Pretty upsetting that we can only use images/meshes that we own, especially when ROBLOX avatars are completely complied of other peoples assets. I had been working on a feature that involves roblox avatar textures that I cannot use anymore
Please add back EditableMesh:Clone()! It previously had a huge benefit since I’m making multiple of the same meshes editable. With some recent changes it doesn’t look like this is possible anymore (if I’m wrong please let me know).
That has unnecessary load time. It’d be nice to be able to generate the MeshPart once, cache it, and somehow be able to clone it along with its EditableMesh that it was created from.
- (I used Win+(+) to use magnifier to zoom in lol)
But just for clarification, Skinned Editable-meshes will work with animations like how normal skinned meshes do correct?