FunFetched

Members
  • Content count

    38
  • Joined

  • Last visited

  • Days Won

    2

FunFetched last won the day on September 2 2017

FunFetched had the most liked content!

About FunFetched

Contact Methods

  • Website URL
    www.funfetched.com
  • Twitter
    FunFetched

Profile Information

  • Gender
    Male
  • Location
    Seattle, WA
  1. Watch out for gl.clear()!

    Absolutely! I also discovered scene.setRenderingAutoClearDepthStencil() to control clearing for each RenderingGroup. However, I also found this: // Multi-cameras? if (this.activeCameras.length > 0) { for (var cameraIndex = 0; cameraIndex < this.activeCameras.length; cameraIndex++) { if (cameraIndex > 0) { //this._engine.clear(null, false, true, true); } this._processSubCameras(this.activeCameras[cameraIndex]); } } ... this is tricky, as there are some edge cases where you might not want this. In my case, I have some UI rendering with an Ortho camera with a different layerMask. Since it's all rendered at Z=0, I don't need (or even want) the depth or stencil buffers cleared before it's rendered. As you can see, I've commented it out temporarily for the app I'm working on. It might be a good idea to add an autoClear option to BABYLON.Camera as well. In any case, I'm now down to one gl.clear() in my game (width shadows disabled), and have gained a good 20FPS on my cheap little test Chromebook.
  2. Watch out for gl.clear()!

    Hello, everyone! I just wanted to pass along some very important information that I just discovered regarding optimization that has been completely overlooked in optimization articles that I've read, and can have a huge impact on your apps! I have a game that pushes a pretty similar number of triangles and commands as the Sponza demo, but I wasn't enjoying anywhere near the same frame rate on slower systems. I fired up SpectorJS, cleaned up as much as I could in terms of draw calls and such, and wound up with a game that had fewer calls, fewer commands, and yet STILL ran a good deal slower than Sponza. However, there was one more metric that I had yet to take a close look at, and that was "clear()". I had 6 of them, while Sponza was using only 1. My game is a first-person-shooter that uses an additional camera to draw UI components, and on a different layer, so game geometry doesn't interfere with it. The player's hands and weapons are also drawn in a different rendering group for the same reason. It turns out, however, that for every new layer and group, Babylon kicks off a gl.clear() (which makes sense), and on systems with poor fill rates, this can absolutely wipe you out. In my case, the engine was clearing various buffers 6 times per frame, including multiple times per group/layer. Disabling Babylon's engine.prototype.clear() entirely made a world of difference in terms of FPS, though I do need at least 1 or 2 gl.clear() calls to accommodate my layering requirements. 6 is excessive and unnecessary, however, and I'm currently investigating ways to minimize that. Hopefully, I can do it all by simply modifying my code, but I suspect I might have to make some small engine modifications as well so I have greater control over when gl.clear() gets called, and just how many times. Edit: Just discovered scene.autoClear and scene.autoClearDepthAndStencil. Setting both to false takes care of... well... one of them!
  3. The artifacts when rotating

    A quick Google search revealed that someone else had the same problem in Chrome, and it turned out that his "Use hardware acceleration" option was turned off. Maybe you're in software rendering mode? Does Babylon even work in that environment? I don't know, but it's worth a check. Open up your Chrome settings, go to the bottom and select "Advanced", and you should see an option for that in there. You'll need to restart Chrome after you change it.
  4. The artifacts when rotating

    I think what we have here is an "action shot" of the screen, so the ghosting of the edges is actually the result of a slow "exposure" as he rotates the object (notice the "two" mouse cursors in the second image). So, what we're dealing with here is an apparent "break" in the edge of the object as it's being rotated. My money is on a v-sync issue, but a quick search of the Babylon docs doesn't reveal any options for that. Am I missing something? I think there's a larger issue here, though, since ThreeJS is exhibiting the same problem. Andrey, it might be something specific to your system configuration or graphics driver; perhaps something to do with your browser settings, for that matter.
  5. Shadow quality automatically decreasing

    This is normal behavior. Shadow maps have a limited resolution, and as you add objects to your ShadowGenerator at greater distances, the amount of ground the shadow map has to cover expands, therefore becoming more pixelated as it scales up. So, it's really not about the number of objects you add to the ShadowGenerator, but how far apart they are. You'd see the same effect with 2 boxes; one at x:0, z:0 and another at x:100, z:100 There are a couple of ways you can deal with this. In my game, I use as small a shadow map as possible and keep the light that is casting it near the camera (so the shadow map stays centered on the player), but I have the shadow fade toward the edges of the shadow map, so that the shadows don't just disappear suddenly. You can have multiple, small shadow maps; one for each object that requires a high-quality shadow.
  6. Pointer lock bug on Chrome with windows 10

    The Windows 10 Fall Creators Update is rife with problems; this being one of them, although it could be argued that it really just exposed a problem with Chromium, since it's the only browser that is exhibiting this issue. I've implemented a "solution" in my game which simply ignores the first mousemove event that moves in the opposite direction, thereby eliminating that big jump backwards in most circumstances. Such events are high enough in frequency that ignoring a few here and there is not noticeable. It's not 100% effective, but it's a huge improvement when the alternative is that your app is basically rendered unusable. I know this doesn't help much when you're relying on Babylon's built-in input functionality, but one could use FreeCameraInputsManager, for instance, to register a new mouse input function to replace the old one.
  7. Sprite blendmode or sprite as particle

    I know this thread is over a year old, but I just ran into this situation myself. ParticleSystem, while handy (and additive, if you want), creates too much new junk for the garbage collector for my purposes, so I wanted to roll my own. SpriteManager, however, doesn't come with an option for additive blending built-in. However, if you're feeling even slightly adventurous, it's super easy to add this functionality to the engine. Pop open your babylon.js and look for this line within SpriteManager.prototype.render (it's toward the bottom of the function): engine.setAlphaMode(Engine.ALPHA_COMBINE); Change ALPHA_COMBINE to ALPHA_ADD and voila; additive blending of sprites! Of course, you'll want to add a flag to SpriteManager so you can enable/disable this functionality per SpriteManager, but you get the drift. There are other things you might want to do as well, such as disabling the depth test draw just above that, so you don't end up with darker additive sprites blotting out brighter ones behind them, but once you know where to look, you can do whatever you want. Happy adding!
  8. Shadow bleed-through

    Yeah, that's the "solution" I'm rolling with right now. If my player is on the first floor, for instance, the light follows him just above his head, below the second floor, so the object on the floor above doesn't get taken into account during shadow calculations. There are still some issues when you're looking at both floors at the same time from an elevated position at a distance, but it's not a big deal.
  9. Shadow bleed-through

    Anyway, thanks for your input! I just wanted to make sure I wasn't missing something obvious.
  10. Shadow bleed-through

    Well yeah, that's just it. I tried that, and got some pretty wonky results, though I haven't spent much time trying to fix them yet. Plus, I then have the issue of what to do with shadows disappearing at a distance. I can fade them gracefully, and that might be okay. I'll tinker with it some more. Ideally, I was hoping to save some cycles and leave the map out of the shadow-casting calculations and just "bake" some shading in there at some point.
  11. Shadow bleed-through

    Let me illustrate what I'm talking about. Does that help? Now, to fix the behavior that is illustrated in the far-right pane, I was thinking that I could change the depth calculation to GL_GREATER, so that the sphere at the bottom (and thus, farthest from the light), would get the last say as to the shadow buffer depth values at that location, but instead, I got no shadows at all. I tried futzing with a number of things, but couldn't figure out how to make it work.
  12. Shadow bleed-through

    It's "correct" in that it's behaving as expected. Since the sphere is between the light source and the torus, any part of the torus that can't "see" the light is indeed in shadow. However, the lower part of the torus can't "see" the sphere, either, so technically, it's not the sphere that should be shadowing the lower part of the torus. The torus would instead be shadowing itself, at least if I had self-shadowing activated. Obviously, it's not a bug, just a behavioral issue that just so happens to be interfering with a special circumstance of my own creation. Check out the image below to see what I mean. Notice the ammo crate at the top, and the shadow it casts on the surface immediately below it. At the bottom of the screen, you can see that the same shadow is also visible on the floor below. This is because my map is a single mesh (an SPS). I have a work-around in place now that isn't perfect, but it's "good enough for who it's for". I'm fading the shadow in my custom shader according to the difference in depth between the shadow buffer and the fragment depth, so the shadow at the bottom "disappears". Of course, it's not actually gone, as you can see in the image in my previous post. I'm getting around that now by placing the light right above the player, so the shadow generator will ignore any meshes that are above it. There are some special cases where it still doesn't work quite right. For example, if there were an ammo crate directly below in the following image, the "faded shadow" from the crate above would actually blot out the shadow from the crate below. I initially thought I could fix this by changing the depth buffer calculation for the shadow map to GL_GREATER, so that only the objects furthest from the light would be considered. However, I ended up with no shadow at all, and couldn't figure out how to make it work, so I eventually settled for what I have right now.
  13. Shadow bleed-through

    http://playground.babylonjs.com/indexstable#XUS5AG#1 In the example above, the sphere is located directly above the torus. As you can see, the shadow that it casts bleeds through the top of the torus and on to the lower portion. Is there any way to prevent this behavior? I have a game where the maps are generated as a single SPS that receives shadows, but objects on upper floors cast shadows that bleed through onto any part of the mesh that's under them, such as lower floors. In my attempts to get around this, I created a custom shader that fades the shadow according to the difference between the shadow map depth and the depth of the caster. While it "works" on the shadow from the object on the floor above (sans the aliasing), you can see where it cuts in to the shadow at the bottom of the attached image. The shadow at the bottom is being cast by an object on a lower level, one that's further from the shadow's light source.
  14. Playground editor cursor mis-aligned in Chrome

    I'm seeing a monaco-colors class in there with a whole bunch of .monaco rules, if that's what you're referring to.
  15. Playground editor cursor mis-aligned in Chrome

    Odd. Just cleared everything, restarted Chrome, and the problem persists. It's really strange; seems like a rendering issue. The X coordinate of the cursor seems like it's scaled to match the window minus the nav pane, while the rest of the element isn't taking it into account. Sometimes, it even winds up smack in the center of a letter. Even Google Canary exhibits the same problem. I'm starting to wonder if this isn't a bug in Chrome.