Baker Xiao

  • Content Count

  • Joined

  • Last visited

About Baker Xiao

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. One more trick I just found out recently was the use of Spector.js You can directly see how many draw calls were made and what each of them drew exactly. Using this I found that the way I drew our GUI using pixi.js was causing way too many draw calls. All our images are from a single spritesheet so I thought they would be drawn with a single draw call, but it turns out that having a lot of text objects in the scene graph would break the batch because pixi.js would render things in the same order they were added to the scene. So having (image, text, image, text, image) would be 5 draw calls, but (image, image, image, text, text) would be a single one... Using this technique we now draw the entire GUI with a single draw call and the improvement on mobile devices was pretty huge.
  2. @RelativeNull thanks we don't have anything ready to share yet, but hopefully soon! Are you using any libraries/engines for networking or writing your own? One of the reasons we started without realtime networking is that we're a bit afraid of the complexity. Does it require a significant amount of investment?
  3. Sure! I'd love to share what we did once we're done with our deadline...
  4. @RelativeNull Every optimization up there was a significant improvement for us. They made our game from almost unplayable to smooth 60 fps on mobile. Our game is async multiplayer, so no realtime networking. But at some point we might add some realtime elements to it with websocket. Can I come to you for advice then? Btw what's the networking model of your game? Regarding the use of SPS, see these gameplays as examples. Each of these effects is made with a single Solid Particle System and performs really well.
  5. @RelativeNull hey I'm doing the exact same thing here! I've got a game targeted for mobile and have been really trying to squeeze out the last bit of performance gains. maybe we can exchange ideas and experiences. Are you targeting desktop or mobile? I think you are already doing a lot of right things that I found useful as well. A few things I can probably add: 1. Disable webgl's antialias and use fxaa. 2. Joining all static meshes into one - I think this depends on how many meshes there are, and how many of them are constantly out of the camera. By merging all the meshes, I think we are basically saving all the overhead of processing individual meshes but this single draw call would end up sending more vertex data to the GPU which at some point would eventually exceed the savings. 3. Keep in mind that JS is single threaded and any heavy chunk of work should ideally be split up into smaller chunks or processed during loading/transition screens, otherwise they cause frame drops during your gameplay. 4. I found that mesh selection can be really heavy. So freezeWorldMatrix whenever possible, and for meshes that are always inside the camera, do set alwaysSelectAsActiveMesh. 5. Recalculating bounding info can also be quite heavy. We do mesh.getBoundingInfo().isLocked = true for all the meshes whose bounding info doesn't change. 6. Make use of the solid particle system for dynamic but repetitive objects. It's better than instanced meshes in most cases. We used it for all sorts of visual effects and it's awesome. 7. Be aware of that garbage collection can be a major cause of frame drops. See for a list of best practices to reduce GC load as much as possible. I pay special attention to anything that's in the main loop of the game and try to avoid creating any object, e.g. BABYLON.Vector3. I usually create a global object and modify it inside the main loop instead of creating a new one in each update. 8. Profile the game with chrome developer tools frequently to identify bottlenecks. That's what I can think of right now. Hope it's useful! By the way, how do you do dynamic shadow for dynamic objects? Can you share more about that? Currently we calculate shadows for all static meshes. And for dynamic objects (characters that have animated skeletons for example) we fake a round shadow with a plane... Is there a good way to do cheap dynamic shadows?
  6. Wish list += a resource manager that just handles downloading, parsing and caching, and is independent from engine or scenes.
  7. Hello, We are rendering two scenes with two different engine objects at the same time, and we already imported a lot of meshes into scene A. Is there a good way to clone some of those meshes into scene B so we can avoid importing them all over again?
  8. Lol that's exactly what I'm doing. But not sure if that creates any overhead to the browser or not... (e.g. would the browser still use the GPU for this canvas even though it's visibility:hidden?) Ideally I want to avoid burdening the DOM in any way.
  9. Hi folks, How do we render a scene to an offscreen canvas? We want to use that to construct screenshots for people to download but we won't show these screenshots in the main game. Currently if we create a BABYLON.Engine with document.createElement("canvas") but don't attach this canvas element to document.body, we get errors like below: [.Offscreen-For-WebGL-0x7fe2e1614a00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete Any trick to get it done?
  10. If there's no solution that satisfies both, one idea is to make it a setting so that the user can choose to optimize towards CPU or memory? For us, the situation is kind of awkward because we just have about 50 particles... using instanced meshes has its own overhead, so I'm using SPS. I would definitely want to give up some memory to save CPU cycles given the low amount of particles. But I totally see that enabling these choices is a lot of work.
  11. Ahhh, I got the picture. Looks like there's a tradeoff between memory v.s. compute..
  12. Hmm... in that case, what's a good way to address the scenario where we need to rotate some of the particles initially but never rotate them again? Right now what I'm doing is to never call setParticles again, but that prevents us from changing the position of the particles as well. Seems it would be a good addition to allow some initial transformations to be baked into the geometry.
  13. Ah I see. I think the positionFunction is a good solution to this problem. Will try it out! Thanks again!
  14. btw @jerome we are running into another problem: as mentioned in the documentation, we are expecting computeParticleRotation=false to prevent updates, but still allow a rotation to be set initially. However setting it to false seems to make all following setParticle calls to reset the rotation to 0. Any idea what we might be missing?