I’ve been fighting with getting a player character animated and, as always, there are complications.  I get that Blender often does things in its own special way but it’s quite frustrating that the process to export an animated character from Blender to glTF and import it into THREE.js is still flaky.  Specifically, here’s what’s happening.

I made a character, based heavily on a model I found on opengameart.org.  The model was not rigged so I rigged it in Blender and created a basic idle and run animation.  As far as I can tell, the export to glTF and import into THREE.js in this simple case is perfect.  The guy runs, I can see the animation names in the console, all is grand.  I thought, though, “It would be nice if I could model equipment separately then just parent the equipment to different bones on the model and eventually I could change the parented equipment programmatically.”  This is going to be necessary eventually, but for now I have punted and simply modeled a sword as part of the character’s base mesh.  This is because parenting separate objects to a bone works perfectly inside Blender.  The sword, in this case, moves right along with the hand to which it is parented with no issue but when I export the animation to glTF, things go funky.  The sword’s orientation goes crazy and it becomes difficult to predict where the sword will actually appear in THREE.js.

I honestly believe this is just something I’m not grasping about Blender but it’s frustrating nonetheless for the animations to work great until I add in the twist of parented objects, then it goes wild.  In order to move forward what I have now is good enough.  You can tell the guy has a sword and once I create the attack animation you’ll be able to tell he’s swinging it with the intention of doing great violence.  Eventually I’ll need to spend some real time with this, and possibly bring in some outside expertise to get everything working correctly, but for now I’m just going to move forward with what works and not worry about it.

I’ve spent the last several days thinking about the overall art style of the game.  I very much like the low-poly look I’ve been using thus far but my concern is that I’ll be too limited if I ever want to add assets that need more details.  The primary thing that comes to mind is faces.  It’s way, way cheaper to just draw a cartoon face onto a few triangles than to model and render geometry for eyes and mouths.  Also clothing and equipment may be difficult to keep interesting and varied if every distinction between one piece and another has to be in the geometry.  I’m not ready to go full-blown Blizzard-style art assets yet, but I’ve starting creating assets that have a single, small diffuse texture attached.  I can then create a color palette on the texture and just assign faces of the mesh to the desired color.  It keeps the low-poly look but also gives me the flexibility to use gradients or even just hand drawn textures where needed.  I’m still feeling all this out, but the versatility of using textures is undeniable.

I’ve also been working on getting a better player character in the game.  I found a nice little human character on opengameart.org and modified it some to suit my needs, then rigged it and created an idle and a run animation in Blender.  I then loaded it up into Lyridia, and lo and behold I have a decent looking character that runs and kind of looks around when he’s not running.  Super cool.  Not sure what I’ll work on next, but I’m excited to be making progress again.

As soon as I settled on Babylon.js I found a viable process for exporting models with multiple animations from Blender in THREE.js.  The glTF exporter for Blender now experimentally, but officially, supports multiple animations.  I created a testing scene then used a very basic rigged human from opengameart.org and made some intentionally terrible animations.  The animation names (like “walk,” “run,” or “sit”) export correctly and they seem to play correctly too.  So it looks like I’m back to THREE.js.  The only real downside to this is that I’ll have to tackle collision detection again.  I don’t really want to deal with collision detection, but at least I’ll have the chance to optimize the system so that it behaves they way I want and doesn’t waste resources calculating things I don’t really care about.  I made more progress on the game using THREE.js than I ever did with any other library, so I’m actually excited to be able to start using it again.  I’m basically going to pick the old code base back up and just tweak it to load glTF files for pretty much everything.  That will take me a while, but hopefully I’m back on track.

As cool as Unity is as a platform, it just doesn’t feel right for this project.  That’s tough because it’s obviously a professional tool and some really cool things have been made with it.  After several days of thinking about it I decided to take a look at BabylonJS again.  I’ve used that library before and it was quite cool, I just remember I got frustrated with the built-in collision detection system.  After spending months with various collision detection algorithms and never having much luck getting anything implemented, minor annoyances with the way Babylon operates seem less significant now.  I’ve been messing around with Babylon the last few days and I already have a heightmap-based terrain with a box character walking around on it, complete with collision detection and gravity.  I’ve been beating my head against the wall trying to keep the character from being able to walk up a very steep slope, but screw it.  I’ll figure that out later.  You also can’t jump, but screw that, too.  I know that can be implemented correctly but if I fight with it too much right now I’m going to give up on Babylon too and then I’ll be back to square one trying to use THREE.js and as much as I love THREE.js, the tools to create assets in Blender and import and use them in THREE.js simply aren’t ready yet and there’s no indication when they will be ready, whereas the Babylon exporter for Blender seems to work just fine right now.  So, for now, we’re moving ahead with Babylon.  It’s open source and it has many nice features, plus I can reuse my existing Node.js server side code with it, so there’s that.  I’ll try to post more frequently now that I’ve decided (again) on a tool to use, and hopefully get back to a regular release schedule as well.

I’ve had my confidence in the Unity WebGL exporter somewhat restored by a little experiment tonight.  I changed the terrain in the game to a built-in terrain type object, instead of just putting a mesh collider on a big terrain mesh.  This seemed to work much better once the game was exported to WebGL without the weird hang ups I was getting before.  The stock third person controller kind of blows, but I guess I can deal with that.  The only real reason I was using a separately modeled object with a mesh collider was to get the low poly look I like on the terrain because the stock tools won’t allow you to do that with a Unity terrain object.  So this means I’ll either have to just deal with the terrain looking different from the rest of the game, ditch the low poly look entirely, or figure out how to make a Unity terrain object look the way I want.  I believe there are assets in the Unity Store that do exactly what I want, so if I ever fully settle on Unity as the game engine I want to use, maybe I’ll pony up the cash to purchase an asset that gives me the look I want.  For now, however, the terrain is just going to be smooth and textured while virtually everything else is faceted with no textures.

On a lighter note, happy birthday Lydia!  You’re lots of fun.

I’ve been away for a bit trying to get familiar with Unity.  It’s a great toolset but I’m just not sure if it’s right for this project.  I’ve been trying to get a very basic scene to export to WebGL and while it works, it’s not exactly right.  I have a terrain object with a collider on it and my player character model moving around with the standard third person controller.  In the game editor you can move around and everything is gravy, but the WebGL export hangs up in weird places.  It’s frustrating because there are WebGL demos that were created in Unity that look fantastic, so I don’t understand why my simple scene is having issues.  I’ll keep playing with it for a while longer and if I feel like I can do what I want to do with Unity I’ll stick with it, otherwise I’ll look at all my options again.

Very few of the tutorials you find on Unity start from scratch.  Almost everything starts with “Download these great assets and import them into your scene” then you just tweak it.  This is fine, I guess, but it’s frustrating when I don’t want to go just buy a bunch of pre-made assets from the Unity store or use the generic stuff that come standard with Unity.  I guess I just have to spend the same amount of time learning it as I did learning (what little I know about) THREE.js.  Since it’s a slick graphical tool it just continually feels like it shouldn’t be so complicated, but then again making games is an inherently complicated prospect, so I guess I should just adjust my attitude a bit.  Sigh.

It really looks like Unity is the way to go.  The whole system is just awesome and there are extensive resources show how to do basically anything you could want to do.  I don’t know why I feel like I’m choosing the “cheap” path on this because Unity is a professional toolset used by game studios all over the world, but I still sort of do.  Of course I don’t ultimately care.  I’ve always said I don’t really care about the way the game gets made, just that it gets made and runs in a browser.

This is a pretty monumental shift.  I’ve spent very, very much time developing a browser-based world editor and generally doing stuff with THREE.js, but the Unity tools are just too good to pass up.  In 5 minutes I made a terrain that’s more expressive that what took me weeks to make with my own tools.  Plus I don’t have to worry about exporting and importing assets.  Unity natively imports Blender files and the whole thing Just Works™.

It will take me a while to get a Unity-based version of the game up to the point that the THREE.js-base version is now, but it should be time well spent since creating the world will be much, much faster and easier with Unity.  I’ll keep posting little updates but things here will be sparse for a few weeks while I basically start over and make some big decisions about how the game will work now.

I really like THREE.js.  It’s fast, light, and easy.  Well, it’s easy to do easy things with.  Unfortunately, the further I get with this project the more concerned I am that I need a more complete set of tools.  The thing that has really set me off the last several days is the pipeline, specifically for animated assets, from Blender to THREE.js.  One of my primary goals is to have the game run without the need for plugins or other installed software, which is what led me to THREE.js and WebGL in the first place.  After doing  a small amount of testing it appears that the WebGL exporter in Unity3d is finally fully supported.  Running a couple of WebGL demos created with Unity3d on my secondary test computer shows me that the WebGL exporter seems to be pretty efficient because the visual effects in the demos are miles ahead of what I’m going right now with THREE.js and it still has a decent frame rate.  Plus some physics and other things are also running in the demos, so it appears to be a viable option.  I’m not 100% convinced yet because there are some real concerns with switching toolsets, not the least of which is the learning curve involved, but I’m going to spend some time getting familiar with Unity3d and I’ll make a determination soon about whether it’s time to switch, or double down and try to create some better tools myself based on THREE.js.