Let there be grass

Penrith was feeling a little bare.  I have some friendly trees, a few buildings, even some random fences and water, but the ground was still pretty bare.  When walking around it was a little tough to tell if you were even moving because the trees might be far off and since there are places where there is little variation in the color of the ground, it was sometimes fairly unsatisfying.  So I created tools to add grass to my scenes.  There’s only one type of grass at the moment, and the whole process is Super Unoptimized™ but it already looks 10,000% better. 

I also turned on shadows for the screenshot above, so that helps.  The tool allows you to basically paint on grass, and it works surprisingly well.  Eventually I’ll need to add in multiple type of grass but for now I’m happy with it and will probably move on to something else.


The design of Penrith Forest is going pretty well.  A big part of pretty much every game I’ve played in the last several years has been water features, so I thought it was time to try and tackle some water in Lyridia.  I’m shocked to say it really wasn’t all that difficult, at least to do the most basic job of getting something that looks like water into the world.  I have a large pond/small lake that now has water in it.  It even has waves on it, which is quite cool.  I need to figure out an easy way to make videos of some of these features because it would be much more effective to *show* the water gently lapping against the shore of the pond than just talking about it, but for now you’ll have to take my word for it that it is cool, and I’m excited about it.

File conversions

I have now converted all of the art assets for Penrith Forest into glTF files.  Before I had a mix of .json, .fbx, and .gltf/.glb files.  While I was doing this I created collider meshes for all the assets that needed them.  I also added in the ability to load double sided meshes.  By default meshes created by THREE are one-sided.  This is an optimization that prevents WebGL from drawing triangles that are facing away from the viewer on the assumption that these triangles will probably get drawn over anyway.  This works fine for most things but for very small, simple objects like grass and flower petals I need the material to be visible from any angle.  This is accomplished by simple putting the word “(Double)” anywhere in the material name in Blender.  This name gets exported and the object loading code looks at the name of each material getting loaded, and if it contains “(Double)” it sets that material to double sided.  This only has to be done once, when the asset is loaded, so it shouldn’t have any real effect on performance and will allow me to make all kinds of foliage as simple planes.

The next thing I need to do is clean up and confirm/re-implement the terrain editing and painting code.  I had this working at one point, but I’ve changed quite a bit over the last several week so I’m guessing it’s at least partially broken.  Once this is fully working again, I’ll put some time into the design and layout of Penrith Forest.

Frustrations and perseverance

I was plugging along converting my tree models to glTF by exporting them out of Blender as .glb files and replacing the references to the old .fbx files in the map when I found a piece of weird behavior.  The glTF files I was loading into the world editor moved strangely.  It seemed like each individual asset would move differently when selected and moved.  This made absolutely no sense because the code to move any object is the same for all objects, but I could see it happening.  I’ve now spent a few days investigating this and I finally figured out it was a bug in what I was selecting.  My assets are structured like this (for now):

  • Scene (Scene)
    • Collider (Mesh)
    • Asset (Group)
      • Asset Mesh_0 (Mesh)
      • Asset Mesh_1 (Mesh)
      • etc.


  • Scene (Scene)
    • Collider (Mesh)
    • Asset (Mesh)

When an object only has one material applied to it (which will likely never happen with a production asset) the exported file contains a Scene object named “Scene” with two child objects that are Meshes, an object named “Collider” and an object named “Asset.”  If an object has more than one material it follows the same patter except that the object named “Asset” is now a Group and contains children, one for each part of the Mesh to which a particular material is applied.  So if the asset has three materials, there will be three child Meshes name Asset Mesh_0, Asset Mesh_1, and Asset Mesh_2.

Updating my selection code to handle both possibilities was not terribly difficult, but it took me a while to actually figure out this structure of the exported files.  I’m sure it’s documented somewhere, but I’ve never actually seen it.

The problem I was seeing was caused by selecting the wrong object.  If I select the Asset Mesh or Group then move it around, its transform is still ultimately affected by its parent Scene object.  So if I move a selected Group like this strictly along the x-axis, but the parent Scene object is rotated along the y-axis, the resulting movement will be unexpected and it will move off of the global x-axis.  Since each Scene object is rotated when it gets loaded I was seeing different translation behavior for each object and it was very confusing and frustrating.  Now that I understand the structure of the loaded files a little better I can select the root Scene object and move it, and everything works the way I want it to.

One of the primary lessons I’ve learned through this whole project is that I have to just keep looking at it.  When frustrations come up, and many have, if I just keep working on it a little at a time I will eventually get past the problem.  Just last night I was seriously considering scrapping the whole thing and starting over with a 2d game engine like Phaser.  Now I’m glad I didn’t because I didn’t even have to change much to make this work, just invest some time and effort into understanding what is actually happening inside THREE.