How can I optimize this drawing on a part's surface mechanic?

I’m making a game where people can draw by walking over surfaces. For each part, I’m using a SurfaceGui with 400 frames in a 20x20 matrix.

Perchance I have a feeling this will be very inefficient and performance-detrimental when I’m making an entire map of these parts (thousands upon thousands of GUI frames), so I was wondering if you all had any ideas that I could make this better.

2 Likes

Why not just place Parts there instead?
Make them CanCollide false & CanTouch false.

That way you only have to add the ones that are being placed. Even if you had all 1600 Parts in the 4 frames you show there shouldn’t be too much lag. I’m guessing GUIs would be worse.

2 Likes

If you have grid, then you can try greedy meshing, it’s technique that allows you to turn smaller shapes into one big shape https://www.youtube.com/watch?v=L6P86i5O9iU

2 Likes

Consider switching to parts (preferably a mesh with one face only to reduce lag) and make use of some cache module (like PartCache) for them, it might also be good to not directly create the parts on the server since that will be more costly to replicate replication wise (lots of useless properties you don’t need, like CanCollide, CanTouch, etc, can all be set on the client), since all the data you really need is a color3, and 1 vector3 for the position of the part. So you can utilize remote events to replicate the parts to all clients. Then you can also apply the greedy meshing algorithm mentioned above my post to combine parts adjacent to eachother that share the same color, into 1 part to save on performance when rendering the parts on the client.

3 Likes