Math is just hard.  I’m an educated person.  I’ve never been afraid of math.  But sometimes it’s just hard.  Especially when dealing with 3d graphics.  I fully admit that there things going on in the background of the game that I don’t understand.  THREE.js does a great job of abstracting away much of the dirty work, but sometimes things come up that have to be dealt with at a low level and that can get downright frustrating.

Here’s what I’m talking about.  I have been working on getting Penrith to the point that I can release a demo-type version of the game.  That means adding objects to the world, modifying the terrain to be somewhat interesting, and testing as much as I can along the way.  This was all going pretty well until two weird things cropped up.  First, my player character started moving *very* slowly.  This was confusing because the movement at each frame is based on the game’s framerate so that the speed at which the character moves should be framerate independent.  I noticed it especially on my faster development machine.  It turns out (I believe) that THREE.js caps the display frame rate to 60 frames/second, but this cap is not reflected by the Clock object.  So if the game is running fast enough that it is looping through my main loop at, say, 100 times/second, then the delta on the clock for each loop is going to register 0.01.  But if the renderer is capped at 60 frames/second, then at each frame the character is moving 1/100 of the distance he should move in a full second, but only actually doing that 60 times/second, so he movement speed is dropped to 60%.  The bizarre thing is that the faster a machine is, the more noticeable the drop.  If a computer was capable of looping 600 times/second, the character would at 10% of the desired speed.  On the flip side, any machine not capable of looping more than 60 times/second will never see this problem.  It was simple enough to just test if the delta time was less than 1/60 and, if so, set it to 1/60, but it was still frustrating to find.

Now, the more complicated problem.  My collision detection system is still a bit of a black box to me so I’m thrilled when it works and slightly befuddled when it doesn’t.  To make a long story short, I had to apply the world matrix of the parent of each collider object to the points of the triangles the collision system is testing against.  Without this tranform the colliders were not rotating and positioning correctly over the rendered objects and I was seeing strange behavior.  Again, it only took three lines of code to fix, but required several hours of testing to find the problem nonetheless.

In any case, math is hard and I’m still moving forward.  I hope to have a version of the game up and running so that multiple players can simply walk around Penrith by December 1st.  I think this is a reasonable goal given how close I am to that point right now.

The world editor is now back in business.  I can add assets, I can move them around and rotate them, I can move the terrain up and down, I can paint colors onto the terrain, and I can save the results.  That seems like a really small list of things that it can do for the amount of effort it has taken to create, but at least it works.  Now it’s time to step back a bit and really design the game’s first area, Penrith Forest.  I have a general picture in my head but I need to really know what I want players to be able to do before I just throw some mountains and trees together.  Obviously the first iteration will be just that, and I’m absolutely positive I’ll make numerous changes as more of the game develops, but this area sets the tone for the entire rest of the game so I need to make sure it makes sense from the beginning.  Hopefully my next post will have some screenshots from the world editor of Penrith Forest!

I’m actually struggling a bit with deciding how to move forward.  There are still many, many things to do before I have something that could be considered a working game, but figuring out where to focus next has been a bit of a struggle.  I’m honestly still a little shocked that my implementation of the collision detection system actually works.  I need to rewrite that whole thing, but I’m hesitant to mess with it because I don’t want to break it and waste time.  I know I talked about broad phase collision detection and spatial partitioning, but I just really don’t feel like diving into either of those right now even though the broad phase thing should actually be quite easy.

I’ve committed to using the glTF format so I’ve been recreating the assets I have now as glTF files.  I also created a pretty nice looking fishing shack that I’ll stick into the world once I figure out how I want to handle water.  I guess for now I’ll continue converting/improving my art assets and working on the world editor.  The editor still works but it really needs to be cleaned up and have some more convenience functions added.  I don’t particularly like working on the editor because it doesn’t always result directly in a new feature in the game, but it’s a necessary tool and requires time, so I guess I’ll just keep plugging away at it.

A basic, working system for gravity is now in place.  Eventually I would like for gravity to work a little more realistically because right now you fall at a rate of 9.81 m/s, not 9.81 m/s².  This isn’t a huge deal, but eventually I want to make it so that falling off a cliff means the character’s falling speed increases until he hits the ground, then use that impact speed to determine how much, if any, damage the character should take in the fall.  Still, I’m really excited a player can now stand on top of a box, or a fence, or whatever.  There is still plenty of adjusting to do.  For instance, I’m not sure what would happen if a player stood on a sloped roof.  My desire is that a character would slide down a steep slope but not on a shallow slope, but that will likely come later.  Now that the major pieces of my collision system are in place, I absolutely have to spend the time to refactor that part of the code to be more usable.  That will take at least a few days, but I’m happy to be moving forward again.

I have incorporated the collision detection system in its current state into the game engine.  This took some time because I was fighting with the Blender-to-THREE workflow again.  Here’s a little sidebar on that.

The recommended file format for working with 3D assets in THREE is glTF.  This format is maintained by Khronos Group and includes important features like materials and animations.  Unfortunately, it’s also been a huge pain to work with so far.  Creating assets in Blender then exporting them to glTF seems to work fine, but working with the imported assets in THREE is just quirky sometimes.  When you import a file it is added as a Scene that you then have to add to an existing Scene.  The geometries are all BufferGeometry objects (which is actually a good thing for performance, but difficult to work with) and you just have to really work at getting things to line up just right.

I wanted to be able to model an asset in Blender, model a collision object separately but in the same file, then import the file with THREE and tell my collision detection system to use the hidden collision object.  This way I can make the asset somewhat complex but still keep a simple collision cage for performance reasons.  I don’t think this should be complicated but I struggled with it.  Partially I still have trouble with asynchronous aspects of Javascript programming and so I was just confused.  Partially it’s just somewhat difficult to do what I want to do with THREE.

After quite a bit of tinkering my system is now working.  I have a weirdly shaped concave object with a separately modeled (also concave) collision cage that I put into a map file.  My engine loads the asset, recognizes the collision cage, and the collision system responds correctly when you walk around it.

This is a big step in the right direction.  Next I still need to do pretty much everything from my last post, but I have a working system already integrated into the rest of the engine.  Hopefully this will keep me motivated to finish the code rewrite, implement gravity, blah blah blah.

I’ve been rewriting the collision detection system for the last few weeks.  I have looked at several different collision detection algorithms over the years but the one that I keep coming back to is in a paper by Kasper Fauerby at peroxide.dk called “Improved Collision detection and Response.”  The primary reason I kept going back to that one is that it included information on the response step, not just how to detect collisions.  Unfortunately, it’s a little tough to follow in places and his code listings are in C++, so taking those and converting them to Javascript has been tricky.  After several attempts with varying degrees of success, I think I finally have it working.  I have a test scene with a sphere that just moves around the x-z plane.  I placed a few primitives (boxes and spheres) and a more complicated object modeled in Blender into the scene.  Without gravity it appears to be working perfectly right now.  The algorithm handles multiple objects close together and non-convex objects as well.  I only have a few objects in the scene but I don’t see a significant impact on performance so far.

This is very, very exciting as is but there are several things I need to implement or improve:

• Code refactoring
  • Up to this point I’ve been trying to transcribe the paper’s C++ straight into Javascript just to keep things simple.  There are some C++ conventions that just don’t make sense in Javascript (like reference variables) so I would like to rewrite the whole thing.
• Gravity
  • The Fauerby paper actually includes some information on how to implement this, so hopefully it will be easy.
• Broad phase collision detection
  • The current implementation runs the rather expensive collision detection algorithm on every object in the scene on every frame.  This is fine for a very limited number of objects but I need to implement a broad phase that can quickly eliminate objects that are far away and thus cannot collide with the player.  THREE automatically generates an axis aligned bounding box (AABB) for every object in a scene, so checking against those is likely the way to go.
• Spatial partitioning
  • In addition to a broad phase, I would like to use something like an octree to further optimize the collision detection system.  There are lots of good articles on this concept, but I probably won’t implement this immediately.

There are other things to do but these are the big ones.  I’ll probably spend the next several days rewriting the code, then stick in a broad phase check, then put the code into the game.  After that I’ll work on gravity, and save octrees for another day.

Overall I’m very excited because a reliable collision detection and response system will allow me to make a basic world that feels interactive.  I can then build off that by adding more “game” type features.