Doing the math is quite easy if you’re interested.
A Vector2 is 2 floats, each float is 4 bytes each, and you said between 200 and 300 points.
So if we plug the numbers in:
2 * 4 bytes * 300 = 2400 bytes (300 to be on the safe side)
2400 bytes / 1024 = 2.34375 kilobytes
A rather small amount of data, probably not something too concerning if players aren’t saving the image multiple times a second.
If this is a multiplayer game the amount of bandwidth used to update two players positions will likely exceed that rather quickly.
If you think of position and orientation saved as a two Vector3s, two players, a tickrate of 20hz you wind up with just two people playing together exceeding the bandwidth in:
Vector3 = 3 floats, position and orientation = 2 Vector3s, player count = 2.
3 * 2 * 2 * 4 bytes = 48 bytes a tick.
48 * 20 = 960 bytes a second.
2400/960 = 2.5 seconds
So two players will use an image represented by Vector2 array of bandwidth every 2.5 seconds just to see each other.
I think tickrates of games are often higher than 20hz also so times may be even smaller.
Now the PNG is harder for me to tell because I do not know the dimensions.
In optimal circumstances a greyscale image should be storable using only a single byte per pixel, so an image of roughly 50x50 pixels should take up the same amount of space pre-compression, assuming PNG’s compression can decipher that an image is greyscale and not waste any bits in compression.
I’m having a hard time finding a good source for the compression level of PNGs, so your range may be a little larger than 50x50.
However if the image is purely Black or White with no inbetween you could simply save every pixel as an individual bit, which would be rather small and easy to develop compression methods for.
For example: If you’re saving a 64x64 image as 128 integers, you could have 4 ints which represent every integer which is 0, saving up to 124 integers of space on an empty image and taking up 132 ints of space in a case where every integer has at least one black and white pixel in them.
Something else to consider is that rendering a complex line renderer of 200+ points will likely be far more taxing on your player’s PCs than simply rendering an image onto a texture, if you have a scene with a lot of photos as you’ve described them it may cause issues on lower end machines if they were all represented in game as line renderers.
Personally, I wouldn’t worry too much about what technique you are using right now, if you run into problems later down the line simply swap to the other technique. There’s a programmer saying I quite like in these situations:
Premature optimization is the root of all evil.
All the best,
Harry.