In my scene i have lets say 1000 planes, they are all various sizes. they are not guaranteed to be the same image. the sizes can range from full screen to small 32 pixels, They all have to be transparent.
What i came up with for performance of this was to create a texture atlas. Which would create multiple atlases if you fill one up. I then used mesh instances so they can all be grouped where they can. this means i have to check a few things to check which group i am in so i can set the master instanced mesh’s z-order. i check collision (quadtree) of every object to see if there is any overlapping, if there is overlapping i have to check the z/order and the position relative to the other in the group to make sure the top left to bottom right render order works correctly if not i need to split up the group and if 2 items don’t share an atlas it also splits up the group. anyways this is getting more and more complex to make sure i hit all the use cases. and the bigger issue is when i move one of these items that i need to recheck the grouping on move every frame to make sure if the z-index goes between anything that i need to split up the grouping again.
there was so much image data that came in that it would create 2 4k atlases. (due to small image on load then larger images after) this works great when there isn’t any overlap but i have some use cases where overlap happens in groups of 1000 which is why the performance question.
so i guess my question is. is there a better way to do this and still get the extreme performance? if i didn’t worry about z-order and used instancing i went from 2000 draw calls to about 13 and all was good in the world. but the draw order wasn’t correct. which is why i started grouping.
my understanding may be off? By using instancing, it does a top left to bottom right draw order when you want to have transparency and alpha blending enabled. 2 different mesh instances can only have a draw order dictated by the parent mesh’s z?
So while i thought my issue was around the zsorting not working with instancing or forcing the draw order it seems to be with the fact i currently have a high orthographic camera setting .
by having a orthographic camera zoom in i was having issues with z-sorting and i assumed it was the instancing. if i change the order to be more extreme distance between items it is showing the correct z-order but when its a lower z i am getting sorting glitches when panning the screen.
the left group of objects has a high z sort, while the right has a low z-sort.
1st uses a shaderMaterial and 500 per item z (works).
2nd uses a shaderMaterial and 1 per item z (doesn’t work).
3rd one uses a standardMaterial and 1 per item z (works).
4th one uses nme and 1 per item z (doesn’t work).
the 3rd one drawn first works as it does not use blending so there are no order issues. The 4th one fully on the left is pretty much the same with blending on so alpha will lose the ordering you want: Babylon.js docs explains the hard part of transparency.
About the first and second they render in one draw the second is suffering from the same issue than the fourth.
The first is a nice parallax trick fixing the issue by ordering the instances on z as you can see here from a different camera
yeah the 3rd ones blending makes sense i don’t know why i didn’t think to test that. first one works for our use case, we originally had everything’s z on .001 between one another. so the move over to a higher z doesn’t do anything besides change the layering we had and where they start/end. Thanks sebavan
