While being on the topic of meshes, are there any plans to add a ResampleMode for textures, similar to what ImageLabels have to properly display pixelated or low resolution textures?
This feature would be incredibly valuable for terrain generation and custom meshes, allowing us to use low-resolution images as textures or custom texture packs, greatly reducing memory usage because currently we’re forced to upload 1024x1024 images. It would pair perfectly with the new Editable Meshes.
It’s a feature we’ve all wanted for a long time and it has been asked before here.
Very excited for this! Would it be viable to have this batch the draw-calls? I’ve noticed currently even the same EditableImage texture won’t batch, and that has been causing some bottlenecks. Thank you!
I don’t understand this. Are you advocating for Roblox to crash on low end devices with no way for your game to respond to it? This is adding a feature for you to be able to handle the failure case… you aren’t losing functionality here.
@FGmm_r2 Is there any chance that EditableImage instances will support additional formats for WritePixelsBuffer? Currently for my minimap system, I store my EditableImage data in run-length encoded buffers to save space and it’d be nice if I could just plug these buffers directly into the EditableImage without decompressing them, since decompressing them takes a fair bit of CPU time.
That’s not what I said. I said Roblox should stop holding the engine back in favor of a minority (low end phones). Old/cheap phones are good now and there’s no reason Roblox should be refusing features, nerfing them, or delaying release due to “think of the people with 2gb memory!” If I want my game to run well on a phone with 2GB memory, I’ll do that.
Even the cheapest/oldest phones now are more than capable of running games normally…
I am talking specifically about the passage you highlighted from the OP. Roblox want to let you take what’d otherwise be a crash, and respond to it more gracefully, with no change in functionality for devices that are more powerful.
Can you be more specific about how this is holding you back?
This is maybe an inappropriate place to ask about this, but one use case for editable mesh is creating meshes that have animated texture scrolling via incrementing and updating all UV . However, constantly invalidating the cluster for each animated mesh seems expensive. Ideally, this would be done in the shader with a simple UV offset parameter, akin to the current Texture instance.
Is there any chance we can get some UV offset parameter for mesh parts? Or will we have to wait for custom luau shaders to get performant animated textures
Thing is, i believe this argument specifically is a gatcha for people that actually want a more powerful and open engine. I do also want a way more open and powerful engine but throwing the argument that low end devices are the minority is just giving roblox (and other high enough people within roblox) a very easy counter point, that being the fact that low end devices aren’t quite the minority. Hey, personally i believe this to an even higher extent. Specifically personally i dislike how games which seemingly don’t seem to do much actually magically take tons of system resources for whatever reason.
The better argument is well, how about roblox letting US do the optimization part and not them? “Oh well roblox believes in a automatic one click solution engine” yea they do, except that’s still not going to get them far and clearly haven’t gotten them very far in the actual game innovation department. Can’t say game’s inner workings have changed much since like 10 years ago. Has developer skill, knowledge and whatever else relating to developers and how they design these games? Yea sure, though the engine is nearly the same in terms of actual power and performance since like a decade ago. The automatic one click solution has never and will never lead to anything. Wish for a future in which roblox gives US the power.
exactly. let us do the optimizations and not roblox
if a game isnt performant for mobile that’s the creator’s fault, and the game probably sucks anyway
I believe a scenario would be EditableMesh/Image instances being either delayed or straight up not showing up. I believe these delays to even failures could result in overall game failures that would require multiple retries from the developer just to make that specific piece/pieces of the game actually function. Maybe sometimes it could straight up just never function. Can’t say roblox is being very specific about that.
And i’m just saying, if it gets to a point in which the engine needs to micro manage the memory usage of fresh EditableMesh/Image instances then there’s proooooooooobably a very high chance that if its not the EditableMesh/Images crashing the game, then it’ll be something else. No point in forcing the engine to micro manage these things for the sake of avoiding a inevitable crash.
Hey, roblox maybe should actually debloat the client/engine and give us the power, tools and systems to actually more effectively optimize our games so that way magically roblox would no longer need to micro manage the memory usage of random features for the sake of preventing realistically nothing.
What format does the pixels buffer use? The code sample makes a suggestion that it’s an array of u32s but it’d be nice to get proper specification on it. Which byte components of the u32 map to which color and the alpha channel?
I’m also going to ask if we’ll get the ability to have multiple texture sources reference the same EditableImage rather than requiring it to be cloned across each one. Maybe a temporary ID system using a hash or GUID?
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.
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.
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
