We are trying to figure out if we implement the following, as we are not sure if the performance gains will be worth the hassle!
So at the moment we have 500x unique PNGs with transparency (each png is 256x256 in size). All of these images are loaded on individual 2D Quads of various sizes.
Now I was thinking would it be more easier on the GPU/browser to instead of loading 500x images, we compile some of these in to X number of Sprites! so rather than loading 500x images, we end up loading say 50 large sprites that have all these images on there. Then we call in each sprite for each Quad.
Can anyone shed some light on this? would it be better all round to do this? Any thoughts would be greatly appreciated, thank you and big love to all.
All of these images are loaded on individual 2D Quads of various sizes.
What are these 2D Quads, planes or sides of boxes?
If planes then it will be worth you timing the following using
(a) 64 of 256 * 256 images then create 64 planes or sprites with one image on each.
(b) 1 of (256 * 8) * (256 * 8) image then create 64 planes using either uScale, vScale, uOffset, vOffset or Front and Back Material or sprites
Most probably the sprite solution will be faster as all sprites of a same sprite manager are displayed in a single draw call.
However, when using textured planes you can use the standard/PBR materials which is not possible for sprites. So, it depends on your use case: if you need the standard/PBR materials, you need to use a plane. In this case, to speed up things, you can use instances or thin instances.
Ok cool, thank you, lets see what my guys say and see what is the best method forward, at the moment, am thinking we go with instances, then enable thin instances once 4.2 is released. But will see how the discussion go
