Giving EditableImages the ability to overwrite the other properties of surfaceappearance (not just colormap) would be an amazing addition!
1 Like
FWIW 2GB Android devices are a bigger percentage of the player base than you would expect.
We have to design these APIs such that it’s possible to use these APIs without crashing on those devices. This is important to a lot of developers.
We do also want to support you doing more complex and expensive things if the user’s device can handle this.
Keep in mind that each 1024x1024 EditableImage is a 4MB buffer. These are probably more expensive (in memory cost) than anything you’re used to working with in Roblox.
Indeed, we can’t fully “optimize for you” here. We are going to expose you to that reality that what is possible to allocate safely may differ per client.
If you’ve ever worked a mobile game outside of Roblox you’ll have some sympathy that dealing with memory on mobile is incredibly hard. Mobile OSes are extremely fickle and inconsistent and there’s no guaranteed safe rules for memory allocation patterns. Allocating reasonable and achievable amounts too quickly can get you killed. Patterns that work one day might kill you the next because the OS wants to run some background job more than it wants to keep you alive. Sometimes you’ll get memory pressure signals, but even those aren’t consistent.
We’re going to try to abstract and rationalize this a bit so you don’t have to deal with the full extent of that sadistic reality that we have to deal with as an engine team, but once you’re now dealing with multi-megabyte objects we’re in this together now.
The system initially will be very cautious and conservative, but over time we’ll make it more dynamic. It will require a lot of experimentation over time to refine, though.
13 Likes
We’re prioritizing getting the essentials perfected first.
The extended mesh attributes APIs in this update are an example of one of the reasons we didn’t add batch APIs already. That would have invalidated those batch APIs. More stuff we’d have to remove and rewrite.
We really want batch APIs. We’ll add them eventually. Likely sometime after the first public release.
2 Likes
It’s one byte per RGBA in that order. You can read it from the buffer as a u32 or as individual bytes, whatever is most convenient for your use case.
2 Likes
Kind of a small thing but it’d be wonderful if we could use the CSG APIs in some point with meshes. I understand converting them into mesh parts is coming later, but if you can’t turn them back into meshes you can’t CSG with them
1 Like
How about developers like you just stop being selfish.
They’re going for the WHOLE player base… Not just the stuck-up ones like you.
Try playing a game like Criminality or something on an iPhone 6, hell even a last gen Xbox like a One S. Runs like absolute crap, disabling every option and putting in on lowest graphics may get you an unstable 40-50 fps on the Xbox, as for the phone…
If Roblox wants to be a respectable engine it needs more options for DEVELOPERS to create the games they need for the platforms they want, instead of kneeling before whatever 9 year old technology Roblox still supports. Don’t fool yourself into thinking Roblox is doing any good for these platforms, unless a game is insanely low end or specifically optimized for these platforms it’s gonna suck playing any game on them anyways.
1 Like
How am I being selfish? I just suggested (disproven by stuff, apparently i was wrong) that <=2GB Android “low-end” users were a minority Roblox should stop catering to so much (note that I don’t have data to back this up for Roblox in specific; i’m going on the general trend in the tech space as of lately which is “phones have been powerful for a very long time”. Android too, even Google and Samsung’s cheapest phones are great with performance. I’m not sucking up for apple here lmao).
A statement like “i wish the engine had more advanced features and rendering” isn’t being selfish or “going against the entire playerbase” it’s just a basic wish considering the majority of players either run on competent computers, midrange/flagship phones (or even “low end” but not by an extreme standard like “2GB memory”), or other devices capable of running Roblox better than what the engine pushes in its current state. My original post was mostly a misinterpretation of this feature not being added due to memory management concerns - an issue for the most part nonexistient on desktop platforms and some higher end phones (S24 Ultra has 12GB and iPhone 16 Pro Max has 8 I believe?)
If the goal is “as least memory as possible on Android” then there is some room for improvement but generally things are all OK right now. On Sober (the android apk on Linux), the client sits on a baseplate at 600MB of memory, 53ms ping, and is chilling at the FPS cap. Assuming Android is idling at 400MB that leaves Roblox a gig to do whatever. This issue will become nonexistent in the coming years as memory becomes cheaper and even “ultra-budget” phones seen in 3rd world countries will get more sensible amounts like 4GB and even 6.
This is fairly immature. Once again, you’re misreading my post. I said I think it should be the game developer’s responsibility to optimize their games, not “Roblox should optimize their engine and feature priorities over me and people with RTX 4090s and 32GB of memory!!” but if Roblox is looking to a feature where professional studios consider them over going with Steam and Unreal/Godot/Unity then a change needs to happen.
I am not going to get into another debate over that because I just had one last week over here:
1 Like
It would be more optimal for SetFaceColors, SetFaceNormals, SetFaceUVs, SetFaceVertices to have 3 separate vertex arguments instead of an array of vertices.
for example:
:SetFaceColors(faceId, vert1Id, vert2Id, vert3Id)
instead of:
:SetFaceColors(faceId, { vert1Id, vert2Id, vert3Id })
It is incredibly inefficient to create a table each time you want to change the face color (or any other attribute). Especially considering that meshes can have hundreds of faces, therefore the overhead of creating a table for every attribute across every face adds up quick.
When I was converting my EditableMesh terrain system to use these new APIs I saw a .2 degradation in speed.
I referenced this issue here as well: Introducing in-experience Mesh & Image APIs [Studio Beta] - #583 by MightyPart
4 Likes
You must also remember that even with a 4gb device most Android mobiles use a significant percentage of that RAM for the Android platform, and background apps. This can mean a 4gb phone can easily have less than 2gb free for Roblox.
Bro, you can’t even run a baseplate game on an iPhone 6s (that has the most optimized software to spare for Roblox). I think your corporate leader should give up on even trying to hold us back from progression. 
Or…they can make the features but make it exclusive to mid-range+ devices and allow developers to lock the game to certain device. 
(And it’s the developer’s choice to)
You’re exaggerating, right?
7 Likes
Why were several methods deprecated from the API?
- GetAdjacentTriangles
- GetTriangleVertices
- GetTriangles
- GetVertexColor
- GetVertexNormal
- RemoveTriangle
- RemoveVertex
- etc
No explanation atleast…?
Not only are they deprecated, they’re also disabled.
1 Like
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.
3 Likes
I fear someone may know that I’m exaggerating, but your case continues to prove that Roblox should just give up on holding us back.
So is Editable meshes in experience now or not? Because title says it is but when i read it says it isn’t.
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.
animating_uvs.rbxl (121.5 KB)
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