I’m looking into scripting pixel art canvases, and I’ve been trying to create canvases on a massive scale. The size I’ve been stress testing with is 300x300 for a total of 90,000 pixels, which is where Roblox starts to break down. I started by subdividing the canvas into nine 100x100 frames, and then completely filling those frames with 1x1 pixel frames. This is obviously a little laggy, but the main problem is that around 80,000 frames, Roblox doesn’t render all of them, whether due to a bug or built-in limitations:
The white is where the pixels are, and the blue is where they stop being rendered, even though they exist. I’ve been struggling with trying to fix this problem for days now, and I really want to make these big canvas sizes work.
I tried UIGradients, because if you place your keypoints right, you can create a ten color gradient with sharp divides in between colors. I thought this would be more efficient and divide frame counts by ten. Somehow it’s even worse, only filling up about half of the canvas before stopping. The last resort is uploading a bunch of decals that represent all the possible 1x2 pixel configurations you can have (my color palette is pretty low in number, so it should be below 1,000). I really don’t want to resort to this, but I may not have any other choice. The other thing I came up with is replacing repeated colors with a single frame, but that greatly depends on what the art actually is. Someone could make something with no repeated colors and break the game.
I’m really at a loss at what to do here, so any help would be appreciated.
TL;DR - Tried to make a 300x300 pixel art canvas and it stops rendering at around 80,000 frames. UIGradient solution I came up with makes it worse. Thinking about resorting to decals instead. How to fix?
I considered using parts before, but Studio would often crash when I got close to 100,000 of them. How would you optimize the part method? There’s probably gonna be several tens of thousands pixels and I don’t want it to crash the game.
When you say Studio would crash, is that with an error message popup or was it just freezing, it could be that whatever code you wrote to generate the canvas and update it is taking long enough to run that it doesn’t let roblox handle windows messages for at least 7 seconds and windows will assume the program has frozen.
Also idk, beyond that is such a high resolution really needed?
It just freezes when I hit stop. That’s all it is. Probably because of insane part counts. Script execution sometimes times out in testing but that’s my fault. As for the question about the resolution, I can shrink it if needed, but I want to see the farthest it’ll go, mostly out of curiosity.
Marking your original post as solution. Thanks for your help.
Hm, you could have a table of colors representing pixels and calculate the index of pixels when needed, and then implement tree structures to group same color pixels or some kind of greedy meshing but you trade improvements in the average case for much more complex code and a significantly worse performing worst case.
Yeah worst cases would be pretty bad. I’m new to greedy meshing so I’ll look into that more, but I think if that doesn’t work out then the highest I’d be willing to go is 100x100, maybe 150x150.
