I think I ended up fixing it, I haven’t touched that for a very long time.
Just a note, it’s a Scripted Tool that dynamically places Canvas on surfaces, not something that is manually made.
Now, let’s say you’d want to continue this 3D Painting Canvas Era onto the Baseplate…
It’s either you fill up the Baseplate with 1024x1024 from start to bottom, or not at all. And doing that raises a question: Would every device remain alive?
You could do complex math to only place one, maybe split all up into chunks mathematically to place a Canvas faster at the right location. But if parts change size dynamically it becomes very complicated.
The point on that test was to have every single pixel editable to paint across surfaces. Something that is very crazy, but also sounds very cool.
You can of course, probably create a 1024x1024 texture and use it anywhere, but that wasn’t the point. The point was to have unique canvas to paint on it dynamically. Since it’s called EditableImages and not EditableRenderingBuffer, it’s probably questionable to what even happens to the memory if you create too many unique EditableImages.
This is my biggest complaint about the roblox engine. It’s frustrating having to resort to hacky or non ideal methods because the entirety of the engine ends up being handicapped. Too many things are trying to be automated and it severely hinders our ability to optimize our game how we see fit. It’s easy enough for us to detect if a device is mobile or low end and let us optimize for those scenarios alone instead of not being able to have a feature at all.
tbh i’d suggest that they hook into this with graphics levels but I won’t because of how it works. It’d probably be good if we had graphics controls like we’ve all been begging for but no so i don’t see that happening and frankly i don’t want it to.
Can we please get a faster way to access vertex positions?
To clarify, I am asking for a function along the lines of EditableMesh:GetPositions() which returns an array structured like this: {[VertexID]:VertexPosition}. This makes it much faster to get vertex positions in tight loops where performance is critical. For reference, it about doubled the speed of a complex calculation in testing.
Why am I asking for this to be built-in?
I ask because creating this array manually takes a shockingly high amount of time just due to how costly it is to do all of the :GetPosition() calls, but that initial cost still pays off. Regardless of whether this is added, having an array set up this way is the fastest way to get positions of vertices, it would just be much better (and definitely faster) if this was built-in.
I have already asked for this, but this would be very helpful and it would probably be best if it were added before the full release.
Again, I just wish to bump this as a possibly less than ideal setup given previous allusions to asset privacy restrictions being very strict. Ideally we should be able to load any mesh/image that we can currently load in our experience into an editable but rather not be permitted to publish any mesh/image which originates from an asset we don’t own. One of the strongest use-cases for editables is visual effects, and that includes visual effects on player characters.
It could be argued that someone could just copy over the pixels / vertexes of an editable generated from an asset you don’t own into a blank editable to bypass those proposed restrictions I just listed; however that could be done anyway with the use of external APIs to load mesh/texture data and parse them into an editable. Ideally, please don’t add any restriction that harms perfectly valid use-cases to mitigate the few bad actors since those bad actors will just find a different way anyway and it will only end up stunting creative uses of the APIs.
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.
