Rendering performance with large objects

[Sorax]

Hi, I need some hints on how to optimize rendering of large objects in pixi (a game level is over 8000x8000) for older machines with slower gpu's. I'm using webgl for rendering. I know that pixi does not support view culling, so I've implemented my own visibility manager. However it's not enough.

1. The background is just a single TilingSprite (400x400 texture), and it affects performance regardless of whether it's cached as bitmap or not. Should I split it in small pieces? Or is there a better solution for tiling backgrounds?

2. Terrain pieces are a combination of graphics, meshes, and sprites, all cached to bitmaps separately. I tried to make them as small as possible, but of course most of them are a lot bigger than the screen. Terrain pieces are only rendered if their bounding boxes intersect with the viewport. And it seems like it's still a lot of work for most people machines (fps can drop as low as to 15).  It seems like I'll have to minimize rendering even more. I guess ideally only visible triangles of meshes should be rendered, but it's a lot of work, as I won't be able to use PIXI.mesh.Mesh(), and will have to reimplement it myself. Any thoughts?

Couple of screenshots included so you'll know what I'm talking about.

[Sorax]

So, no ideas? Nobody ever made a big background with pixi.js? 

[ivan.popelyshev]

Your question is too wide. Of course its possible to optimize that thing, but pixi is made for demos,  certainly not for big full-HD games on old machines. Even Unity cant give you that. There are too many opimizations specific for those kind of games you have to be aware of. If we just put it all in pixi, well, library will be too big and people will complain "OMG, another phaserjs". We prefere to put those things on user-side

For example, I do not to use cacheAsBitmap at all and rely on static buffers instead. 

https://github.com/pixijs/pixi-tilemap can help in your case for sprites, but for meshes I suggest merging multiple meshes in your screen with same tilemap approach: when camera hits the bounds, move the "window",  re-calculate all the meshes inside the "window" and put them in one drawcall (mesh).

I cant say more, unless you are ready to give more information about the project and provide a demo that i can profile.

Also, z-buffer optimization can work on older machines, i have special hacks for it, I can explain how it works but I dont share that code freely, that'll be killer feature of my soon-to-be-released fork: https://github.com/gameofbombs/gobi