• Content count

  • Joined

  • Last visited

  • Days Won


FunFetched last won the day on September 2

FunFetched had the most liked content!

About FunFetched

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location
    Seattle, WA
  1. 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.
  2. Shadow bleed-through

    Anyway, thanks for your input! I just wanted to make sure I wasn't missing something obvious.
  3. 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.
  4. 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.
  5. 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.
  6. Shadow bleed-through 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.
  7. 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.
  8. 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.
  9. Hi, guys. I'm having some cursor-alignment issues with the latest Playground editor. I suspect is has something to do with the new navigator pane, but I can't be certain. I've attached an image showing where my mouse cursor is, vs. where the text cursor ends up when I click. If I were to type at this moment, characters would be inserted immediately after the 'V' (where the mouse is), with the text cursor lagging behind. The problem is more profound the closer you get to the right-side of the window. I'm using Chrome 61 on a MacBook Pro. This doesn't appear to be a problem in Firefox or Safari. Edit: Speaking of Firefox! I just noticed that using the arrow keys to manipulate a FreeCamera causes the entire window to scroll slightly. Don't forget that event.preventDefault()!
  10. Authorative server and multiplayer options

    Fully-authoritative (it's the only way to go). Well, the only thing that isn't is the player's rotation, which doesn't matter, as "hacking" it is pointless. There's simulation on the client side, which uses the same code that I have on the server, but that's just to allow instant-feedback for movement inputs. The player's position is then nudged (or warped occasionally, if your connection is poor) if it gets out of sync with the server.
  11. Authorative server and multiplayer options

    Oh, interesting. I had no idea that there was a window package for NodeJS. Makes sense, I suppose. The only thing I'd be concerned with there is that it might be using a lot of CPU to do things that you don't need done on the server side. On the other hand, if you never start engine.renderLoop, then maybe you're okay.
  12. Authorative server and multiplayer options

    I wanted to re-use some math functions on the server-side so I could use the same code to simulate player movement on both ends. I copied the relevant portions from BJS to my server. It was easy enough, as those portions don't expect a .window object. What you need sounds to be a lot more complicated, so I'm not sure how you would proceed. My maps are just simple grids, so I coded the collision detection portions myself.
  13. Shell Shockers

    I'm using some Babylon on the server side, but basically just for the vector and quaternion math. Since Babylon at large expects to run in a browser (and therefore, a 'window' variable), I just cut-out the portions that I needed; portions that don't require window, and put them in a new file. I'm not using a physics engine, and the collision detection I'm doing myself, because I wanted to keep it as simple (and therefore, fast) as possible. The map is just a grid, so collisions just come down to a simple box test.
  14. Shell Shockers

    It's actually entirely server-authoritative. There's simulation on the client-end, which is probably what you're looking at, but the server has the first (and only) say as to when a player is actually hit, where he can move, etc. That makes connection quality paramount to successful play, so you might make a note of your ping as well. Generally, for any first-person shooter, anything under 100ms is considered good. Problems arise when it gets much higher, and especially when it fluctuates a lot. I'm quite close to the USA server, and my ping is generally under 20. I had a 45-kill streak myself once, so 90+ doesn't seem entirely out of the ordinary. People who play FPSes competitively on a regular basis have a serious advantage, I've noticed. Make sure you aren't downloading anything while you're playing. Steam, for instance, can be a killer if it happens to be downloading an update in the background. As for your frame rate, there's probably a way to increase that, but not knowing your system specs, I can't be sure. I get 50-60 pretty consistently on my MacBook Pro. A guy I know has a pretty powerful PC, but it was running significantly slower until he tweaked something. I can't remember if it was a driver update, or a WebGL setting in his browser. There's some good information here regarding browser settings (including Firefox) in regard to WebGL: Edit: Actually, the game won't run at all if you don't have WebGL enabled, but Firefox does have a lot of settings for it. Enter about:config in your address bar, and search for webgl.
  15. Shell Shockers

    Absolutely; that would be great!