will pixi-layers improve renderBatched performance for a scene with multi paralel containers

[lancety]

hi @ivanpopelyshev , my game looks like below screenshot, the player running among trees. Currently all sprites of player and tress in same container, there are several renderBatched call in each frame, each frame takes 3ms for about 40 trees, and 7ms for about 150 -250 trees.

I had a look several pixi performance related discussion, seems some improvements like cachAsBitMap wont work in current container based zIndex order sort solution since it need to updated when player move behind or before it. Also put same sprite with same base texture in same container (so it batch render them) wont work which is why I want to try layers.

So wondering if using pixi-layers to arrange the z order, and put the player and tree in their own container will help?? player using its own texture, all trees use one big base texture.

Thanks for any advice.

[ivanpopelyshev]

Need to see this example, without any cacheAsBitmap's. renderBatched shouldn't take that much time.

[lancety]

hi @ivanpopelyshev , thanks for reply, you can try my game here https://galaxy108-staging.online/game/index.html#/

the pixi render logic is in pr.bundle.7e190b.js the default map dont have much trees where player respawn, you can try a different map by changing the map seed number

Here are the pixi and plugin version "pixi-particles": "^4.3.0", "pixi-picture": "^2.0.3", "pixi-spine": "2.0.5", "pixi.js": "^5.3.3",

[lancety]

default map when zoom in, the average frame time is about 1.5 - 2 ms for a map where lots trees around respawn position will be around 7-9ms

[lancety]

I think it is better to explain the main workflow of this render logic, it might be helpful for a quick investigation on your side

• the map is based on a convex hull mesh https://mapbox.github.io/delaunator/
• each region in the mesh has its own 2nd dimention convex hull mesh
• each region is a container
• sprites in each region is in the mapped container
• when zooming or dragging map, the logic will initiate the sprites in container or remove them
• if you zoom far enought but still showing tree detail, that will be about 3 regions witdh, if there are many trees in this zoom level, there wont be sprites or container add/remove or show hide container behaivor, and take a performance snapshot, you will see the average frame takes very long time 6-10ms if there are several hundreds of trees

[ivanpopelyshev]

ok, lets look at GPU side first:

Trees are actually last drawcall, not on this screen. Here i see many triangles that are actually dynamically uploaded every frame, through a batcher. You should prepare it in big meshes, maybe use something like chunks. That way pixi wont have to go FOR through all those things and their vertices every frame. Something like tens of PIXI.Graphics each has thousand vertices, or PIXI.Mesh , also tens with thousand vertices.

[ivanpopelyshev]

Oh, wait, you are right. The 45k vertices call is actually TREES, out of screen. You should really cull them somehow

[lancety]

so the time taken in each frame is actually rendering the trees, but some of them are out of screen. then I need to fidn a way to limit adding the tree sprites if they are out of screen. then what else I can do to improve the peroformance further? sounds like with this amount of trees it does need to take this much of time right?

[lancety]

if I zoom out the map little more to show region level tree icons, the frame time reduced a lot, normally the icon represent 3-5 trees. I feel the larger size of sprite instance affects performance more than reducing the size of sprite texture. (I tried reduce the tree texture size from 200px 200px to 20px 20px (sprite size not change, the time taken did not reduce much)

[ivanpopelyshev]

Further? I have an algo that does separate static/dynamic sprites and allow to not FOR through all of them every frame, preparing buffers before, and it even allows player sprites to go through it. At the worst, when everything is moving - its same as vanilla pixi performance. However, this code is not open-source because i didnt have time to prepare it for general usage, BWAHAHAHAHAHA. So the only way right now for you is to make your high-level algo for culling better.

[lancety]

I understand it is hard and takes time to make things generic. Your feedback is really helpful every time I have question, and feedback is very quick, much quick than other git repo maintainer. I will try to reduce the trees, and see what else can do.
Thanks a lot~~ It is improtant to know the performance is not affected by any bugs I made~ :D

[lancety]

if there are only simple tree texture sprites without any animation, or special effects/filters, or player spines. then can I use the ParticleContainer?
when zoom in very close the frame time should be ok, it will be great to show all the trees or even more decoration sprites when zoomed out on region level without showing any dynamic sprites or effects.

[ivanpopelyshev]

Yes, you can also use pixi-tilemap in this case, its faster than ParticleContainer for static objects. However, you still need a high-level culling algorithm, even if its stupid chunks.

[ivanpopelyshev]

That case requires you to know how pixi works from inside. All those cycles, you have to look at them. That's a hard version of "100k bunnies" problem, when you solve something like that - you become a master, we welcome you to the club :)

For example, here is project that managed to make their map with lots of vector graphics and compressed textures at the same time: https://clashofcoins.com/

Usually, solution can be divided to two parts:

1. high-level solution: chunks, sweeping window, you write whatever your fantasy allows
2. low-level: ParticleContainer, tilemap, actual webgl solution that does not know about your case, it just renders data that you give it. each part is done independently, you can switch low-levels with same high-level, or high-level with same low-levels.

It is not possible to do universal solution for all games that want big map. Solution should be made by human :)

[lancety]

Thanks for the additional comments @ivanpopelyshev . I have several years experience as front end developer, also have knowledge using aws cloud and nodejs. I quited my last job 2 month ago, and trying my best to make a multi player web tech based 2d game. I have no expeirence about webgl just started learning, I knew pixi long time ago, and surely I will become a master of it as well :)

[lancety]

is there a complete documentation explaining the whole workflow of pixijs lib? I read the pixi.js kindle book, that did not cover things too deep. Only option is reading the source code and finding answers in the forum?