103 – I suck at shaders

After so much time, I still haven't mastered shaders! Not even something simple, like bump mapping with ambient bump mapping and spherical harmonics. I've been always suspecting that there is something wrong with my bump mapping and this comes down to three things:

• My bump maps suck. I have done them myself and while things like the stool seems to work OK, the barrel from some angles always seems to have the metal rings protrude instead of extruding.
• I think that the equations I am using are not exactly correct. The point light one was clearly wrong and I fixed it, but the fix makes no sense mathematically, at least for me.
• The weights of each component are not well enough tuned.

In order to better locate my errors and increase quality, I am going to do three things:

• As a background task, I am going to study in depth (again) normal mapping and spherical harmonics. All the theory that I can get my hands on, making sure that my equations are correct and I understand why.
• Get my hands on some sample normal mapped meshes that I can use as reference and try to improve my own maps.
• Introduce a secondary rendering mode to the engine.

For now I only managed to introduce the new rendering mode. The engine still renders things as it used to, but with the press of a button ('l' in my case) you can switch to a second rendering profile on the fly. Using this I managed to compare parameters more easily and came with an all new rendering profile. Be prepared, because I am going to spam you with before/after screenshots.

So here is a before scene with a  lot of barrels and stools:

And the after shot:

Notice the added depth illusion on the barrels and stools, but also it is pretty clear that the rings on the barrel are not extruding the right way. I am going to go around this scene and post before/after comparisons form different angles:

Getting those images aligned in Blogger was harder than needed :). I hope they are in the correct order. The effect is customizable. Here is another profile that should look exactly the same to you, unless you know what to look for, and even then it will probably looks the same. Well, it is subtly different and alters the properties of light circling objects.

You can come up with a ton of settings and the parameters have a wide range of valid values. Here is what happens if you go outside the valid values:

I kind of like the new profile. I can't wait to get my hand on some proper normal mapped meshes done by professionals and use them to fine tune my new profile. Also, spherical harmonics produce some unnatural results for quite a few input values with this new profile (carefully avoided these values for the screenshots), so that should be also put on the list of things to fix.

But in my engine I don't have only one light source. Let's try out the personal torch, which in the new skill tree will actually be a spell in which you need to invest ability points:

From the front it makes a big difference, because there are two lights meeting heads on. From behind, there is less of a difference between the two profiles. The personal light is best used at night though:

This was from behind, with the moon illuminating the front of the objects. Let's take a look at a shot from the front, where we can see first only the moon light in the two profiles in dark, then with the personal light on:

I grow tired of these orderly scenes:

So, what do you think? I think this is a massive improvement. I still need to try it out with some proper normal maps. I hope I can fix spherical harmonics and get my hands on multiple sky-boxes, so we can see the harmonics in action, with the skybox contributing in real time to the illumination of objects (the contribution is minor). If I somehow am not able to fix the harmonics with this new profile, I might get rid of the atmospheric illumination element of shading. It is cool, but not really needed.

Screens of the day 34 - Fogged

Oh boy, a new screens post! The blog is back on track!

With the latest changes to world scale and the new skybox, I complained about some very ugly artifacts near the far plane when moving around the camera. Let's take this scene as a sample:

You can see the fogged terrain in the background. It looks OK, I won't complain that much about it. The problem is that even moving the camera a few pixels changes the shape of the terrain that intersects the far plane:

As you can see, looking a bit to the right has caused most of the distant landscape to disappear.

Moving yet again causes new terrain to appear.

What is the solution for this? Well probably I am going to need to implement a proper terrain some day, with LOD. Probably geo-mipmapping. Then you can have a lot of low quality terrain in the distance, move the far plane farther away and scale all fog values so that any popping, if it exists, is barely visible because it is so distant. But my terrain implementation is crap and it has a very shitty draw distance.

Like I said in the last post, I can't fix this for now. But I can hack something together just for Snapshot 002 to get rid of the moving far plane artifacts:

OK, view distance is a lot lower, but at least you can't see the artifacts. Let's fine tune the values and see a few more shots:

The only problem is that it does not behave good when looking from high above down:

Oh well, good enough.

I also noticed that the skybox should be rotated, because the light shines from opposite direction as my terrain is illuminated. Wrong :):

Better:

Finally, a few posts ago I mentioned that with the freed up resources from simpler terrain rendering, I would either add more materials or implement triplanar mapping. I did some tests with triplanar mapping. I wanted to show some screenshots, but they don't look that impressive. Yes, things look slightly sharper at steep slopes. The effect is expensive, so until I either increase its quality or performance, I won't be using it.

102 – Snapshot 2 is going to be great

The theme for snapshot 2 was "RPG", so let's leave that for last. Take a look at this screenshot from the engine:

I should really start cutting out the window border for dramatic effect! Anyway, in this screenshot you can see the new "hub" approach I have taken. The engine has now two centralized states, one meant for exploring the worlds and one for using the tools available in several windows with a traditional mouse  driven interface. You can swap anytime form game mode to system mode by hitting "`" on your keyboard.

When the little menu in the top left corner is visible, you are in system mode. Here you will have access to normal tools, like the world manager which is basically a much more advanced save manager and the game options. Normal things for a game. But you also have access to the engine's constructions set, which is build in seamlessly into the experience. You don't need a separate executable, learn a different tool, wait for loading, push updates or fight a sluggish interface. The tools from the construction set work instantly at any point and the changes are reflected live in the running game. The price to pay for this is minimal, except for the development time :). One note though: when hiding the system hub you will revert back to your loaded game. If no game has been loaded, you are left with an empty screen. Take a look at the screen that greats you when you boot up the engine:

OK, you probably won't have any saved maps. After creating a few you will get this. The purple background signals that no map is loaded. In the future there will be a clearer indication for this. If you load a map you will be placed normally into game and the system hub will disappears. Press "`" and it will be shown again, with all windows in the same state you left them (except for the world manager, which closes by default when loading a map; but if you show it again it will be in the same state as you left it before the close).

The world manager now lets you also give the height in percentage for the newly created maps. By snapshot 002 it will be updated to support entering the world seed too.

Another new comer is the options window. Currently it only supports just the main graphical options and it does not read or save them from disk, so every launch of the engine you have to change the options if you don't like the defaults, but it is a good start. It will be updated soon.

You may also have noticed the skybox. Adding this was done through the material editor, which received a healthy upgrade in functionality.

But before this I added primordial support for modules. Modules describe all the rules and content of the game and are designed with mod-ability in mind. Once the support is rich enough, the era of hardcoding is done for. For the engine to work and look the way it does, you need tot know what materials and meshes to load, what materials to assign to which part of meshes, what meshes to assign to the abstract in-game objects, what physic behavior to assign to them, etc. This was done in the past by hardcoding these relations, but a fully moddable experience needs to add support for creating these relations visually in the construction set and save them as data in a format designed to be easily modded. So now the material editor can add new materials and it also saves them to the main module, which for now is in XML format.

After the editor and and core engine skybox support was added, I was left with a white skybox. Using the material editor, I assigned the textures one by one, seeing the changes reflected live on screen:

I also added night support for the skybox:

I know believe the night is not dark enough.

But the skybox raises a new set of problems. In the past with the sky being a single color and fog having the same color at its maximum intensity, the far clip plane of the terrain was perfectly hidden. Now you can see it and it is rather ugly! My solutions for this: don't look at it. This is very hard to fix and impossible with my current view distance that is very low. So for now I'll ignore it, especially since it will take me months to find a solution for it.

There has been another major change: the engine now uses logical coordinates. In the past I have had many issues with the world scale. I had to change it around several times, a lengthy and error prone process. Now the engine uses logical coordinates and every dimension is expressed in abstract "meters". When going from logical coordinates to real ones, meters are converted to unit-less vertex coordinates at a fixed scale. Every world can have a unique meter size, but once I find the perfect one, all worlds will use the same scale. The scale is a hidden value anyway.

Adding logical coordinates support took me about a day. After adding support, I reduced the scale of the world several orders of magnitude. This had the unfortunate effect of changing subtly the look and feel of the world. Physics behaves differently and fog had its look changed.

So finally let's talk about the RPG elements. I'll write a post about my design for character progression, but for now I added a stamina bar with fairly complex rules to it. You have different rates of gaining and loosing stamina, together with an exhausted state again with its own rates. Governing this stamina bar and your overall mobility is the new skill tree:

Currently it is only a single tree, but the skill points can have drastic effects. 8 of the 9 points are implemented, with the last one being scheduled somewhere in the next few weeks. Instead I'll add further trees.

The progression in the trees is horizontal. The tree has mostly passive abilities, but the passive ones can have such a drastic effect that they will change your active gameplay style. Green outline means a new ability, yellow outline is an upgrade to a previously unlocked green ability and blue outlined abilities are mutually exclusive with another blue outlined ability near by:

This is the build I use during testing. The abilities are 100% implemented and even slightly balanced, but the tooltips are not complete or correct. Since balancing changes every week based on my experience with the ever evolving trees, the tooltips won't be 100% accurate for months. This is a common problem in games, with world of Warcraft being a prime example :P.

The skill tree works closely with a new class added to the engine: the Player class, which manages all stats and attributes and is responsible of spending and gathering resources like stamina. 

Currently the player character is reset to default at each game launch so you'll have to reassign you ability points.

So that's about it for the main features that I manged to squeeze into Snapshot 002. After some more polish and testing, it should be uploaded on Monday.

A fair warning regarding snapshots. At this early stage, save game compatibility is basically 0. Most new snapshots will render your previous saves useless, so a new set of generated worlds for each snapshot is called for.

Changelog:

• Implemented to system hub.
• Implemented primordial module system.
• The world manager can now control the height of generated maps.
• Enhanced material manager: you can add materials and it saves the material list. 
• Basic options menu added.
• Player character class has been added to keep track of the player's status.
• Ability trees have been added. Currently only about half of the mobility tree has been added and implemented.
• Skybox support.

Bugfixes:

• Fixed most of the bugs with changing states in the system hub.
• You can now copy & paste in the engine as you can in any windows application.
• Material editor no longer crashes when loading a non-existing texture.

Tworenas Snapshot 001

So it is finally time! I think I managed to get a very stable minimal version ready that will serve as the foundation of all further snapshots. This doesn't mean it is not buggy. It is probably very buggy and might do anything from displaying these bugs to crashing to resulting in World War III.

So a few things before we get started: you will need Microsoft .NET runtime in order to execute the engine. Probably version 4.0 will do, but I'm not sure how Microsoft packages their distributables: do you get 4.0 from installing 4.5 or is 4.5 an add-on. Anyway, 3 or 3.5 won't do. You also need sadly probably the last version of XNA 4.0 that will ever see the light of day. Finally, you need a computer with a GPU that can handle XNA HiDef profile. In a couple of snapshots I might get around to providing two versions, one for HiDef and one for Reach. And one more thing: currently the engine is optimized to run at 60 FPS or higher. If you are getting lower framerates, physics might not sync up perfectly with this rate and it may seem less smooth to you. I'll try to make smoothness less reliant on framerate in the future.

There is one more important thing to mention: I did not manage to find time to create a configuration dialog, so the engine will run in 720p on high quality settings by default. You can press Alt-Enter to make it fullscreen and you can reduce the quality at runtime, but you'll have to do this every launch. Persistent settings are coming in snapshot 2, at least in the form of an INI file. Vertical synchronization is on by default, so you shouldn't see any framerate higher than your monitor's refresh rate.

BY AGREEING TO DOWNLOAD THIS SOFTWARE, YOU TAKE TOTAL RESPONSIBILITY FOR ANY CONSEQUENCE RESULTING FROM THE USE OR MISUSE OF THE SOFTWARE. I AM NOT TO BE HELD RESPONSIBLE FOR ANY POSSIBLE HARM THAT CAN BE CAUSED BY THE SOFTWARE NOR DO I GUARANTEE THAT IT IS FIT FOR ANY PARTICULAR PURPOSE OR THAT THE INTEGRITY OF THE SOFTWARE WILL BE PRESERVED WHILE BEING TRANSFERRED ON ANY AND ALL MEANS OF COMMUNICATION.

I hope that legal mumbo-jumbo is able to protect me from whatever ill consequence that may arise. Any piece of consumer electronics can break down and it would be a shame if by coincidence that would happen as someone runs the engine. This is very unlikely because it is not that heavy on the system and it should only get lighter.

Link: Snapshot 001

This isn't a permanent location for it. I know that it won't get any downloads so I can safely store it on my Dropbox, but when i think that something will get downloaded, I'll put it somewhere else so my Dropbox won't get clogged up :).

It is just a little bit too early to give you a  full list of controls. With snapshots 2 having more of a user interface, I'll leave snapshot 1 destined for guesswork.

Changelog: 

• Terrain is not longer a singleton. The engine officially supports any number of terrain objects, but for now only uses one.
• Terrain support has been moved 90% to the general purpose library. The library is now 440 KiB of code.
• Created a window creation helper component to make GUI code shorted and a primordial screen system to isolate game screens.

Bugfixes:

• Every single smallish bug I could find and fix.
• B003: Massive memory leaks in the new word manager. Every time you use it to load or generate a new world, some resources remain in use. Eventually you will run out of RAM. Fixed. 

101 – Snapshot 1 almost done

I order to make good progress on the snapshots, I am trying to give each one a theme or some major feature to keep me focused. It is very easy to go all over the place, do a lot there, but end up with nothing to show.

The theme for the first two snapshots (at least) is "a mad scramble to get the basics done". Snapshot 0 in particular was super mad, trying to get a bare minimum of systems working good and giving the engine a major smoothness overhaul. Snapshot 1 shares this theme, with again a major focus on smoothness. I'm not expecting any downloads on the snapshots, each one being more like a personal milestone, but if somebody does download one of the early snapshots, I want them to say "This has barely any features". I don't want them to say "This is an unpolished pile of shit". In the above scenario, that person has above average objectivity, because this is the Internet after all. No mater what quality you achieve, people are going to hate.

What I'm trying to say is that each snapshots needs to have one fairly polished and very smooth feature rather than a bunch of small incremental changes to 5 or more features. For the first two snapshot this feature was the terrain.

And I achieved major speed up on everything related to terrain. The change is so significant like replacing a 3 year old computer with a new modern one.

On top of snapshot 0's changes, I did a ton of new optimizations that resulted in added smoothness. But the major improvement was moving the tangent and binormal calculations over to the GPU. Not having to update these on the CPU has freed up a ton of resources. One small caveat is that the method by which tangents are computed is different, thus the terrain is just a little bit brighter. And I have encountered exactly one visual artifact. This can't be true and I'm sure there a tons of such smaller artifacts, yet this one is the only one I managed to find. Before screenshot:

After:

So the artifact is minor and I kind of like it. Makes the terrain just a little bit less ordered there.

Another thing I changed is the quality levels of rendering. I had a slightly outlandish and somewhat more polarizing shader set in use to render terrain. Initially it was a response to normal mapping not being strong enough, but eventually it got enhanced with a ton of stuff, like spherical harmonics and fancy detail mapping, so it kind of lost its original goal. Also, in the meantime I grew fond of a more traditional look for terrains. So I did a "back to basics" on the shaders, removed some of the bells and whistles and came up with a more comprehensive set of 3 quality levels: low, medium and high. The previous 5 were too much, especially since they defied a simple naming scheme. Quality 4 was not lower in quality as Quality 5, but it was faster. Now low has no normal mapping, medium has normal mapping and high has some extra effects for better contrast.

Low:

Medium:

High:

Now that the world is smooth enough, one question remains? How do you get a world? I could package a small world inside the snapshot. But that is just one world, plus worlds are really big. I can't put out weekly  300+ MiB package. Eventually snapshots will get over 1 GiB and by then I'll need to create an incrementally updating patch system. But I am getting ahead of myself. So I need a way to manage worlds. Introducing, the world manager:

I decided to go with a persistent world set. A world remains in your list until you explicitly delete it. But you can do anything with that world without deleting it, including deleting all the world content, regenerating it, doing major automated editing on it. So there is a major difference between deleting a world and deleting the data inside it. If you delete the world, it is gone for good and without a trace, together with you character, skills and inventory. Deleting the data just gets rid of your maps, so you can adventure on a new set of maps. Your character, inventory and anything that you have acquired remains. It is like moving to a new area of the world. In the future this might even be implemented and a world might have any number of regions.

The world manger can be brought up on its own or when exploring a loaded map and can load a new map asynchronously:

After first creating a world, or after you cleared the data from it, you are given an option to generate a new terrain:

The import option is disabled and not implemented, but it will allow you to load a heightmap bitmap in a number of popular formats in order to create a map. I will add support for normal grayscale bitmaps and also for floating point textures, in raw format of standard ones.

Map generation takes ages so it is good that it is asynchronous. OK, maybe not ages, but it takes a lot of time. My final hopes for this engine includes very complex procedural worlds and that might take up to 20 minutes of generation time for large ones. Currently the generation is slow because diamond-square algorithm is slow. I need to dig up my old Perlin implementation and use MT with it.

The world manager is mostly done, yet feature poor. It will evolve over time.

The main problem right now is that I am having some major memory leak issues.

Anyway, snapshot 1 is mostly done. I need to test it until Monday and maybe I can even get rid of some of the memory leaks. Snapshot 1 is going to buggy as hell, maybe even crash, but it is stable enough given the time frame.

On Monday I'll post again with the download link.

The theme for snapshot 2 is going to be "RPG". Snapshot 2 will introduce the concept of channel rate, mana, overcast, stamina, exhaustion, rest, a fully functioning (but for now quite small) skill tree, player stats and two implemented skills.

Changelog:

• World manager!
• Tangents and binormals are now computed in the vertex shader. This reduced memory consumption and greatly improved terrain editing and loading snappiness. A few minor visual changes resulted from this.
• With the new performance levels, terrain chunk streaming wait time has been reduced 10 times, making streaming far more responsive while keeping walking at all speeds snag free. On very strong computers, the wait time could be reduced, halved or even quartered.
• The number of terrain quality levels have been reduced from 5 to a more manageable and easier to understand 3. These quality levels avoid the more outlandish shaders and give a pretty "standard" look to the terrain.
• Massive speedup of map loading from disk. On my computer, for a 64 square kilometer map, it went down form 2.7 seconds to about 0.5 seconds. Reading floats from disk in C# is slow. Who knew? Still, physics creation in memory was yet not improved and it still takes about 2.5 seconds, so 3 seconds for the first load. After the first load, live streaming kicks in so you don't need to wait for load times.
• Using the above trick and applying it to terrain texturing streaming, I improved chunk stream in time from about 4.0 ms to 3.4.
• The chunk allocator is now capable of pre-initializing the buffers that will be in us, so every time a chunk that was in use before is reused, some computations can be skipped. And with an additional optimization round for those calculations, I reduced the average chunk load time from 3.4 to 2.8 ms.
• Changed the way MSAA is set up. It should give a minor performance gain for all levels of MSAA. If you are just about at the minimum specs to run the game without MSAA, this boost might be enough to allow you to run at around 60 FPS with 2x and rarely 4x MSAA.
• The game window restores mouse position after returning from another window.

Caveats:

• C003: Partially fixed, since stream delay time has been greatly reduced and chunk load speed increased.
• C004: Partially fixed, again by the improvements that helped C003. As a new addition, the streamer is now partially biased towards the camera position and will first try to bring in a set radius around the camera and then proceed to go from corner to corner. The radius is not yet large enough to cover the entire streaming area. Need to be made as big and ten I need to add frustum biasing. Once these two things are done, this caveat is fully solved.

Bugfixes:

• B001: Turning on physics debug information at he same time with SMAA causes render to fail. Only an one pixel thin screen diagonal gets some color rendered. Temporary fix: turn off SMAA when using physics debug information. Fixed. Was rendering the SMAA full screen quad in wireframe because debug physics sets the render mode to wireframe.

Bugs:

• B003: Massive memory leaks in the new word manager. Every time you use it to load or generate a new world, some resources remain in use. Eventually you will run out of RAM.
• B004: Loading a map right after generating one is inexplicably slow. A second load, loading a map generated some while ago or loading after a game restart loads at normal speed.

100 – Announcing "Project Tworenas" and second round of snapshots

Hello there! Long time no see!

Since last time, I've been up to several things, but most of them not related to this project. One thing that was related to this was a pretty successful port to DirectX 9. For now I won't be porting further because I do not want to replace the physics engine.

In order to pick up the pace on this project, I am starting weekly or sometime bi-weekly snapshots. The goal of each snapshot is to add functionality and stability at a fast pace, while minimizing random rewrites (which I am prone to) and trying not to break anything from snapshot to snapshot.

It is also time to distance myself even further from the "Dwarves & Holes" project, so it is my pleasure to announce my new project code-named "Tworenas". It is not a new project, just a rename. For months actually I had a "C:\Tworenas" folder with the engine install.

Which brings me to the first issue: the engine is installed there because it can't handle yet loading resources from a changing folder. This and a few other things must still be improved before the first snapshot, so this week I'll consider this one Snapshot 0 and I won't release it. Next week will be Snapshot 1, the first public release.

But what is Tworenas about? It is meant to answer two questions: can you take a 3D game level editor, add some classical RPG mechanics to it and make it fun? And can a physics playground be fun? I already know the answer to the second question. Even in its current limited state, skiing around and checking out the physics interactions can be fun, especially when they surprise you. I remember the first time I walked fast towards a barrel rolling down hill and without desiring it, my character climbed on top of the barrel and before you know it I was "riding" a barrel down hill. But I don't know the answer to the first. That we'll find out in a few dozen snapshots.

Each snapshot will have a changelog posted, even Snaphot 0. Below I will detail the changes from the last video you saw to Snapshot 0. Some snapshots will also get an "engine features" video.

Changelog:

• Terrain uses vertex buffers again by default. For larger terrains, this can speed up terrain rendering by a factor of 3-4. Terrain can now change on the fly between using vertex buffers and arrays on a chunk by chunk basis.
• Terrain has customizable anisotropy for both close and distant chunks. Setting these values low, together with the above mentioned vertex buffers use has greatly increased rendering speed, especially on weaker hardware. It is now possible to have 60+ FPS on Intel HD chips, albeit at low to very low quality settings.
• Natural physics reaction of objects to terrain shape change. When you raise or lower the terrain, objects lying on top of it will shift and slide naturally with the curvature change of the terrain.
• Terrain persistence: the entire terrain is streamed live to the disk when changing it. When loading the same map, all changes will be preserved, together with camera position too. This basically gives you a persistent load/save system. Maps in this engine are different from other games, because you can always edit them on the fly. This means two things: baking of map data is not possible, since baking takes a long time and editing should be done in real time. This means that everything about the maps must be dynamic, from creation to rendering with lighting and all effects. The second thing that is related to saving is that maps are big: a 64 square kilometer map takes up 512 MiB with one height point at each meter. If I were to double the resolution, a single map would take 2 GiB on disk. Such large maps can't be compressed. So in the first versions at least, the engine won't use a traditional quicksave/quickload feature, one in which a new quicksave is a new save on disk. The disk would fill up really fast, plus the engine prides itself in very low loading times. So the engine will use a map based quicksave feature. Anytime you do something to the map, from changing the terrain to dropping a barrel, the map will be saved. There is no going back to a previous save state. This is done in the background, so you don't have to wait for an on screen spinning icon to stop spinning like in a lot of modern games. And saving will be disabled during combat, so if you die you will get back to the point a few milliseconds before the combat started. Snapshot 1 will feature only terrain saving, without clutter saving.
• Major RAM optimization. RAM consumption is a lot better now, but it wouldn't hurt to get it lower. I am investigating Vertex Texture Fetch in order to store terrain data more compactly, but I am yet to figure out a way to compute normals, tangents and binormals based on a bitmap heightmap in the vertex shader. This computation must also be fast enough to be done each frame for large scale terrains that also use a heavy pixel shader.
• To preserve memory, terrain texturing has had each channel reduces from floating point precision to a byte. Currently, I couldn't find any visual difference between the two, indicating that 8 bits/channel are enough.
• Terrain is slowly starting to transition from singleton to multiple terrain object support. Once this is done, some interesting things are planned, like small floating islands.
• Individual terrain vertex updates.
• Added mouse event support. Also used this mouse support to try and fix some of the Neoforce activate/deactivate GUI inconsistencies when going from first camera mode to window interaction with mouse mode.
• Editing a single height point has become much more atomic. In the past the entire chunk needed to be recalculated. Now, smart offset computation algorithms allow one update to result only in a few vertex changes. Unfortunately, this doesn't work yet with tangents. If a tangent change is needed for terrain, the entire chunk must be recalculated.

Caveats:

• C001: Terrain in the engine is chunk based. This means that some editing operations need to update more than one chunk for a singular change. This happens on chunk borders. Editing terrain at chunk borders is slower than in the middle of the chunk. The worse case scenario is a chunk border where four chunks must be updated for a single terrain write operation. Possible solution: some optimizations can still be done to improve this, but the corner case will always be slower.
• C002: Edited chunks change from vertex buffers to vertex arrays in anticipation of further changes. Editing a chunk once is rare, the user will probably do multiple edit operations, so it is a lot faster to not initially recreate the vertex buffers. Currently, the vertex buffers are not recreated after an edit unless you walk so far away from the chunk that it is no longer needed and then you come back. This means that if you continuously edit terrain for long periods of time, increasingly more and more will change from vertex buffers to vertex array, slowing rendering somewhat and eating more RAM. Possible solution: Future snapshots will periodically go over the list of chunks and if a chunk hasn't been edited in the last N seconds, it is probably safe to change it back to a vertex buffer. Temporary solution: this isn't a major issue and is not a memory leak, since the maximal wasted extra RAM from arrays is deterministic and based on map size. If you feel that after minutes/hours rendering has slowed down noticeably and you suspect this is the cause of it, just close the game and reload. Reloading gets rid off all arrays.
• C003: Since large terrains require a lot of streaming power, chunk streaming is spaced out, making sure that not a lot of chunks are streamed back to back. With the addition of terrain texturing persistence, the time to stream a chunk has increased a lot. This is only noticeable on slower computers with slow/full disks. Possible solution: As a first fix I'll space out streaming even more, first streaming in the geometry, taking a few milliseconds break, then streaming in terrain texturing. In the future, streaming will be multithreaded.
• C004: Streaming is currently based on the whole region that needs to be brought in. This means that if you were to teleport to a random part of the map, streaming would start somewhere in your vicinity, but not guaranteed near you. It might take up to 3 second for the terrain under your feet to become visible. It is still there and physics works just fine, only you can't see it. This is not noticeable that much since you can't teleport yet. Possible solution: biasing streaming based on camera distance and frustum intersection, so the first chunk that is streamed in is always the one bellow your feet, then the ones in front of you, finally the ones in the back. Also, if a teleportation spell has a short period in which character control is taken away from you, like a mediation or spell cast animation, chunk streaming spacing can be reduced to zero, streaming in at full disk read speed. Animation plus a fade in/fade out effect should be fast enough to stream in most of the new surroundings so that no loading screens are necessary.

Bugixes:

• A ton of smaller bug fixes all around the engine in preparation for snapshot release. From now on, bugs will be given a code so I can track them.

Bugs:

• B001: Turning on physics debug information at he same time with SMAA causes render to fail. Only an one pixel thin screen diagonal gets some color rendered. Temporary fix: turn off SMAA when using physics debug information.
• B002: When skying at high speed, after landing from a high jump the character can rarely get stuck in the terrain. Usually the character will start rising up, slowly getting ejected from the terrain, but sometimes this won't work. Temporary fix: moving the camera around a lot fast while repeatedly pressing jump should free you.