I’ve begun writing my world editor.  I can see that this is going to a be a very big, very important part of this whole game project.  So far you can add a terrain with a button, although the terrain is just a flat subdivided plane, and you can add a test asset, which is this weird looking cube thing.  Blender is the only 3D authoring tool I’ve used much so taking a cue from its controls you can right click on an asset to select it, and it glows red.  You can then right click anywhere off of an asset to deselect.  This isn’t working 100% correctly and will be improved eventually, but it’s ok for now.  If an asset is selected, you can press ‘g’ to enter translate mode, then press ‘x’ to move the asset along the X axis, or ‘z’ to move the asset along the Z axis.  Other than the THREE.js orbit controls, that’s it so far.

The list of things to do is too large to even start it here, so I won’t bother.  Once I can load a scene in the world editor, save it, then load it in the game I will feel like it’s a real tool, so that’s my focus for now.  When that very basic functionality is working, I’ll start adding features to the editor and hopefully see some real progress in the game world at that point.

So far the rewrite in THREE.js is going fairly smoothly.  I have a very simple random terrain generator and a character model that loads.  A simple follow camera follows the character around and the character stays on top of the ground thanks to a raycaster.  The Penrith Farmhouse is also loaded and you can walk around (and through) it.  I also have fog set up so that anything past a certain distance just fades into the distance as you walk around.  This is most of what I had set up in the BabylonJS implementation, but without as much content in the world and without collision detection (other than the ground).

Some things I’m excited about:

• Performance is still good at this point, even on my very low end testing PC.  If I shrink the display down to 800 x 600 I can get 60 FPS.  This is good news because I would really like the low end hardware requirements for the game to be very low.
• Lighting is going to be fun in THREE.js.  I didn’t play around with the lighting much in BabylonJS but I can totally see individual lamp posts actually casting light, and maybe even using shadows for players with beefier hardware.
• No twitching.  One of the things that really bothered me about the built-in collision detection system in BabylonJS is that right from the start it made my scenes very jumpy.  For instance, just walking around on the terrain made the camera jittery.  It wasn’t a huge deal and it was probably something I was doing wrong anyway, but it made the game feel manic and made me nervous that it happened so easily when using that engine.

At this point I need to address the first drawback of using THREE.js as a game engine which is there are no native scene creation utilities.  I can’t just model a whole scene in Blender then import it like I can with BabylonJS.  Honestly, though, even if I could I don’t think that’s a great process.  If this is going to be a real game, it needs a real scene editor so that I can see the changes I want to make as they appear in the engine, not in another piece of software.  That being said I will still make heavy use of Blender to create assets for Lyridia, I just need a tool to import those assets into a scene and move, rotate, and scale them in a way that is efficient for THREE.js.

So that will be my project for the next several days, or possibly a few weeks.  I’ll need the ability to load and save terrains with height map images, import and position, rotate, and scale assets, and save scene files.  If I can get all that working then I’ll start looking at some more advanced options like tweaking materials, adding lights, etc., etc., etc.

I must say I’ve always liked THREE.js.  It’s clean and relatively straightforward, it just isn’t a game engine.  And that’s actually okay because, ultimately, I want the control of writing the game engine part myself for Lyridia.  I’ve been doing some basic testing with loading assets into a THREE.js scene and it’s not hard.  One thing THREE.js lacks that BabylonJS does well is exporting scenes from Blender and then loading them in the engine.  I believe that with THREE.js I’m going to have to load individual assets then place them in the scene.  This method should work fine but it means I will definitely have to create a scene/level editor because I won’t be able to use Blender for this.  If I can do this well it will be a great asset and should allow me to separate asset creation in Blender from scene creation in my tool.  It will also allow me to ensure my scenes are as optimized as possible.  For instance, if I have 200 copies of the same tree in a scene with each tree just scaled and/or rotated, there’s no reason for the client (browser) to download the tree model 200 times, and if I’m writing this all from scratch I can make sure that’s the case.  My next step is to load in a simple terrain and re-attach keyboard and mouse controls so that you can walk around in my new barren 3D world.

Since I seem to have convinced myself that I need to rewrite the game in THREE.js instead of BabylonJS, I’m going to take a minor break from working on collision detection.  As I said in my last post basic collision detection and response is working.  It’s still a little glitchy and needs a lot of work to be applied generally, but since I know it can be done I think I’ll put Penrith Forest together with THREE.js and then try to get the collision detection and response system in place from there.

Well, the short version is that I have a very basic collision detection and response system working.  My test scene has a sphere that I can move left or right.  If the sphere hits a triangle it slides along the surface of the triangle.  I even put two triangles with different slopes next to one another and the sphere slides along one then changes pace slightly as it slides along the other.  I simplified the code from the Faurby paper I was using and there’s probably some stuff I’ll find out later I’m missing, but the basic concept is working.

My next step is to generalize to code to handle meshes instead of individually defined triangles.  This is “narrow phase” collision detection and is relatively expensive to calculate, so I’ll need a broad phase scheme as well.  Fortunately, THREE.js includes a utility to generate an axis aligned bounding box around a mesh and these are pretty easy to use to eliminate most geometry from consideration during the broad phase.

I’m still plugging away at getting a functioning collision detection system built.  So far the collision detection part seems to be working somewhat reliably, but the collision response part is still largely non-existent.  March 1 is still a reasonable timeframe and even though this is slowing things down somewhat it could definitely be time well spent if I can get this working.

I’m going to write a collide-and-slide collision detection system in Javascript with a fully functioning demo using THREE.js.  I’m writing here so I’ll actually do it.  This will take me time.  If I am very lucky and don’t get burned out immediately, I might have it done by March 1.  I’m putting everything else on hold while I work on this.  If I can make a general purpose collision detection system then my primary purpose for using BabylonJS will no longer be valid and I’ll probably rewrite Lyridia base on THREE.js.

After admitting I was stalling by working on putting some grass into the game, I’ve now stalled some more to improve that process.  Now instead of “solid” grass I can make double sided flat grass and it shows up correctly.  As a result, a chunk of grass that looks virtually identical to the solid grass but is actually made of double sided triangles has just 15 faces.  I can pare that down some if I make the grass model a little simpler, so I’ll make some other grass models at some point that are just dead simple.  I used the tags feature in BabylonJS to accomplish this.  Flat geometry can now be tagged as “doublesided” and when the model is loaded its material type will be converted to double sided by turning off backface culling.  Backface culling should remain on for most objects for performance reasons, but the ability to selectively turn it off on objects modeled in Blender is very useful.

I’ve been looking at the controls in BabylonJS and so far I’m not a fan.  The engine does a lot for you, which is good, but it also hides a lot of the details behind poor documentation, which is not good.  There’s a whole action manager system that seems very confusing at the moment.  If I try to just put in a good old fashioned addEventListener for mousedown or mouseup I get very weird results.  It will pick up left mouse clicks if the right mouse is down, but not otherwise, which is frustrating.

So, I’m going to punt.  The controls are good enough for now and I’m going to move onto other things.  Eventually I may not even use BabylonJS.  I would actually much prefer to use THREE but as it’s not a game engine there are some features it just doesn’t have.  Or maybe I’ll eventually figure out BabylonJS well enough to use it correctly, but I have definitely found myself frustrated by things in BabylonJS not working the way I want to and the root cause seems to be hidden from me.  That sounds like some kind of conspiracy, but it’s not that.  The engine just tries to do a lot for you and if you don’t use it correctly it doesn’t throw an error, it just doesn’t do what you want.  I’ll come up with my next steps and post them here soon.