Saturday, August 31, 2013

107 – M-m-m-m-m-m-multi Mod

Hey, I'm done with Snapshot 8. I'll package it after I write this post and I'll start working on Snapshot 9 tomorrow. I need to have something cool  for snapshot 10, the half point of this development cycle. But I'm not making it available today, it is only Saturday.

So, new features: multiple mod support! Take a look at the new editors:

Tee new design language and background structure intended for code reuse is at work here, but the features are the things worth noticing. First, we have a few buttons for filtering the content. Right now we have only a handful of items so it is not that useful, but once we'll have hundreds, this will help navigate the list. The "MSC" filter is already very useful, since when I turn it off I am left only with 3 items, 2 furniture pieces and one container, getting rid of terrain, skybox and grass, things you will rarely edit. The list of filter buttons is closed, but I'll add all the useful ones.

Then we have the list that shows first what mod the item belongs to. There is now support for adding an item to a given mod, renaming, removing and the disabled button is used for moving items from one mod to another, but it is not done yet.

On the right side of the material window you have a redesigned panel, this time only with two textures: diffuse and normal. The specular map is gone to save video memory and sampler calls, and there is an always one check box that allows you to use the alpha channel of the diffuse map for the specular map. I don't see a good scenario for having it turned off, but it is there for foresight.

The models window got the same treatment, but the right side panel is still underdeveloped.

To stress test the mod system, from now on all new content will come in separate mods. The final product I want to ship will of course feature a singular mod, but until then the list will just grow.

So from today, there are two mods available out of the box, "main" and the new one, "column". Column just defines a material and mesh for an asset that you may saw before, but it is newly available, the column:

This model was created by BrewStew but was never textured, so now it is textured. The look is not quite final and in the snapshot you'll get a texture with a bit of AO on top of it and some more tweaking.

The editors are very important, but they are not gameplay editors. One major part of gameplay will be building, and these are not building gameplay related editors. You need to have materials and meshes, but gameplay wise it is the rules that count, not the assets. You could theoretically use only colored boxes and gameplay rules to achieve similar results. The skill editor can be considered a gameplay editor, but next week the first building related editor will be introduced, the third major editor: the list editor. Most rules can be described as lists.

The first list has been added to game already, but there is no GUI for it: the grass list. Using this list you can control the meshes that you want to use for grass. A rudimentary list editor will come next week, allowing you to change the grass mesh and introduce the first major list: the containers. An item in there will allow you to choose a mesh that will be used as a container, together with what size should it have (independent from the original mesh size/scale), what physics shape it can have, how many items can it hold, the maximum weight, what kind of items it will accept, etc. Using this list I'll add the first two real containers, a usable barrel and a chest and implement player inventory with moving items from the container to the player and back. Heck, if I have time, I'll introduce a cooking pot too, where you can only add food. Not promising anything on the cooking pot. And it won't be functional for cooking.

I also changed the terrain response to dropping a foundation with some smoothing. An original terrain like this:

Will become like this:

The shape is a little bit more natural and rounded:

You'll see it sometimes in a new video, when I repair and reintroduce house body building.

I don't know if I ever mentioned the goals for the 20 week development period, but one of them was to take any idea or primordial feature I have shown of before, and if it was a good idea, no mater how half assed and non-viable the initial implementation was, to turn it full featured, stable and integrate it smoothly into the engine in the hopes that what will turn out will begin to resemble a real game.

So, next feature. Hmmmm. Ah yes! Remember how I said that the alpha channel will be used for speculator maps? I updated the shaders for this. In the process, I created a new shader file and copied over all the good content, while leaving out all the bloat. The new leaner shader is a lot easier to edit, so I added a bunch of new debug modes to make sure all the assets are on par. This is the raw textured debug mode, perfect for noticing seams in the texturing:

This is the raw normal map debug mode, perfect for noticing seams in the normal map:

And this one is the raw debug mode for speculator mapping:

It is working properly, trust me. The reason you see white is that the tools I am using are really shit and are bad at creating mip-mapped files with an alpha channel. I had to manually assign an alpha channel to each mip level and I'm looking for better tools:

Ah, pipeline woes!

Wednesday, August 28, 2013

Tworenas Snapshot 7

Here it is, Snapshot 7, late as usual. I was not able to get it out on Monday, but for snapshot 8 I'll do a feature freeze on Friday, package it and on Saturday I'll start working on Snapshot 9, so I hope that next time thing will be out on schedule. Anyway, the fixed release schedule is just for me, so that I can get used to some release discipline.

The first big feature that nobody will notice was the finishing of the Level class. This is pretty much the last step in my major internal structure refactoring. There is no such thing as a perfect design, but I'll get a great millage out of this one: generic renderer, game specific renderer, standalone terrain and grass components, level, rule set and modules. The introduction of the Level class was very disruptive and I spent a couple of hours fixing null pointer exceptions. Hopefully I fixed them all.

For GUI, I introduced a new set of conventions, both in code and GUI design. I'm going with a more compact and panel based representation, inspired by some other game engines. Here is a sample:

Looks about the same, but in the background things are different. Until snapshot 10 I need to finish both the refactoring and the fundamental mod GUI.

Then I uploaded this video:

I don't think that I'll go with the dropping from the sky them. I'll try to go with an organic build/progressive update scheme, and if this does not work, I'll try the Assasssin's Creed III Animus Simulation fade in. Anyway, most of the systems will be the same, so I had to fix this. The foundation button has been disabled for quite a few snapshots. That was no placeholder, dropping and terrain deformation worked, only it was far too slow. Setting the foundation is extremely difficult and time consuming, both as development and CPU time. You need to:
  • Determine if this is a good place to drop. Currently, I'm always dropping, but there are some places where it is not a good idea, like on an almost vertical wall or on a patch of terrain with huge height differences. You need to sample the terrain in a wide radius and determine somehow how disruptive the terrain change would be and reject spots above some threshold.
  • Deform the terrain. Very time consuming on such a large area. I''ll try to animate it in the future, not just for the looks, but for spreading out the task over time. The deformation is particularly hard because of chunked nature of terrain and the myriad of caches and pools it uses. They all must be updated, or else you get memory leaks or the terrain will disappear under you feet.
  • Remove the grass. Again, same story: chunks and caches.
  • Do something about objects that are under the falling platform. I did not do anything with this. In the future they will be destroyed.
  • Do something with objects near the point the impact that don't get crushed. I did not do anything with this. I'll apply some explosion like effect, making the objects get thrown in a direction based on their angle to the point of impact, simulating a shock-wave.

So it is hard and I'm not done. The last two points are not implemented. And you also get ugly results when putting platforms very close one to another. And you can drop them on your head. It won't kill you, but It might get you stuck in the terrain. So still a lot to do.

Oh, and persistence. When loading the map the platforms should be still there. Unfortunately, I did not have enough time for persistence. I did not want to half ass it.


Link: Snapshot 7

Monday, August 19, 2013

Tworenas Snapshot 6

I am just realizing it right now: am I repeating the unfortunate naming incident of the planet Uranus? How do you native English speaking folks pronounce "tworenas". Is there any hidden "anus" in it?

So, snapshot 6 is out! Like I mentioned, this is half bug fixes, half graphics.

I made a ton of screenshot detailing the performance of the engine with the new tweaks, but I realized this is no place to show them all. So in words: on an Intel HD chip, performance was bad at 640x480: 30 fps. So I optimized the new effects and got a good improvement, but performance is still between 30 and 39 fps with light shafts:

So I added an option to turn them off:

Still, this did not greatly increase performance, The high quality terrain  terrain with multiple light support is a performance hog. So I went in and wrote the new multi light support shaders for low quality. High:


This helped a bit, but even the low quality is heavy because of the light processing, so I added a special variant to the shaders that is used when no lights are present and this shader is used on the appropriate cells of terrain.

So eventually I managed to squeeze out around 60 fps with light shafts:

Now, the default settings are on high and 1280p. I did some testing and setting them to low while maintaining resolution and light shafts gives you between 32 and 45 fps. Not ideal, but this is Intel onboard. Dedicated chips have an easier time. I can run the engine at 200-400 fps :).

Snapshot 7 or 8 might bring something really interesting, but I'm not sure I can pull it off yet, so not telling you what it is or making any promises.


Link:  Snapshot 6

  • Extended the skill tree and introduced the skill editor.
  • Skill choices are now saved. (There will be a new option in the world manager to reset the skill points.)
  • Grass system optimized to use advanced pools and caches while avoiding C# GC.
  • Grass looks updated, with slope coloring and dynamic light support, with a maximum of 5 lights/cell.
  • New Renderer component to isolate rendering from game logic.
  • New ModRuleSet component to isolate mods and game rules from the rest of the game logic.
  • New Grass class that abstract away the entire grass system into a simple to use component. The Grass class is part of the game library.
  • Entire rendering and content management system refactored!
  • Light shaft!
  • Debug visualization support for vertex normals, pixel normals, tangents, binormals, depth.
  • Mesh tangent seam correction at all UV seam included into to pipeline.
  • Low quality terrain profile is back. Medium is still M.I.A.

  • Fixed so incorrect tangents all over the place. In consequence, normal mapping pops more than usual and no longer changes direction based on angle.
  • Some stability fixes on device change
  • Grass lighting bugs fixed. Grass light can still sometimes be just a bit too neony, but this is not a bug, just a light scaling factor that is too high in the rendering profile. I will properly scale the lights when a GUI is introduced so you can control live the strength of illumination for the entire world.
  • Fixed a major and quite old terrain bug. How tor reproduce: raise or lower terrain near your feet, then walk so far away that you can't see the spot you edited anymore. I mean that the spot should be outside of the fog barrier. Then walk more, to be absolutely sure that that region of the terrain has been removed from RAM and all caches. Then return to the original position and notice that a chunk of terrain around the spot you edited is invisible. You cans till walk on it and edit it as usual, and the changes are saved, the chunk is just invisible. Reloading the save fixes this. Because of the huge distance you needed to traverse from  the edited piece of terrain and return, I did not notice this bug before. The fix was one line of code.

Sunday, August 18, 2013

106 – Trinity

The plan for snapshot 6 did not go 100% as planned. I wanted to do a full bug-fixing run, but halfway though it tuned into a full graphics and graphics bug fixing run. Anyway, the changes are so substantial that I'm bumping up the version number in snapshot 6.

The first reason for the version bump is major internal refactoring that while only about 60% done, it has already payed off in spades. As the project size increases it becomes harder and harder to maintain. Back in the day I split the project in two, a general purpose game library and the actual game and this helped a lot to maintain things under control. But lately, the Game class was getting too large. Splitting it up into a hierarchy of classes only helped spread the complexity over multiple files, not reduce it.

So I introduced the holly trinity:
  • The Rederer. This component babysits all the almost 20 classes responsible for pushing pixels to the screen and takes care of loading resources, render targets, rendering profiles, post-processing, etc. Delegating all the rendering tasks to this class helps make the game render engine agnostic. The migration will be done in two phases. Phase one is already done and consists of creating the class and making it sure that it offers all the rendering services. The Game class uses these services to render the world. For phase two, I will inherit from the Renderer class and create a child class that renders my world using the services of the parent, thus achieving true decoupling between game and rendering. Phase two is not done yet.
  • The ModRuleSet. This is a collection of modules and rules that define how a world is set up and what assets can be used to build what. You give it the list of modules that you want and it will try to merge them into a master rule set. It also handles loading materials and other assets that might be needed. And it also includes some system variables, like the way the wold looks under lighting, how long the day is, what is the run speed, etc. While I have no intention to vary these from world to world, the engine is completely capable of it. The ModRuleSet is fully implemented.
  • The Level. I named it level to be more generic, but it is actually a world. This class holds the real data related to a world, like your character, terrain, grass, placed objects physics, etc. Think of an instance of ModRuleSet as the generic class for a world, and an instance of Level being a specific instance of that class. The Level class also handles loading and saving. This class is not yet fully implemented.

So with these classes, the Game class need to instantiate a Renderer and tell it in broad strokes what it wants to do, then you create a ModRuleSet and give it a list of modules and finally you load a Level from disk. And you tell these classes do their thing! And they do. Now, the Game class is only responsible of input, GUI, managing your interaction with the world and the game mechanics.

The second reason for the version bump is the major improvement in mesh tangent space continuity and everything that depends on this.

Implementation wise, I have three problems with my lighting scheme. First sometimes the normal mapping effect gets inverted and looks very strange. This is particularly bad with the barrel and you can see this in a lot of screenshots and videos. Heck, you can see it in some videos I did in other engines using the same assets, which lead me to believe that maybe not my shaders are to blame. And you can see it in last post's screenshots. Anyway, I'm getting ahead of myself. Second, there is nasty bug with point light attenuation. I have a fix for this which I used since day one, but it is hack. I would like to find a real solution for it. Third, there are some nasty seams in the meshes where the UV mapping continuity breaks. These seams combined with normal mapping create very ugly results. This is partially due to the textures not being seamless, but also there is something else wrong. Something very bad!

So I went forth and tried to fix as much as possible. The new debug mode visualizations helped a lot. Also, I started being active on the GameDev forums (mostly asking for help :P ). Using the vertex normal visualization I determined that vertex normals are correct on the meshes. Pixel normals are not, but the normal map is fine. You compute the pixel normals using the normal, tangent and binormal of the vertex, and since the bi-normal is computed, it was a safe bet to try and inspect the tangents:

Bingo! You can't see from this angle, but the barrel also has a discontinuity in the tangent space on the back side. These meshed have some craptastic tangents.

I googled it and I found dozens of threads on several forums. It seem that having normal mapping seams is an extremely common problem and those forums were mostly without a proper solution. The problem is caused by the way 3D modeling programs have a continuous vertex list across smoothing groups, even if there is a break in the UV mapping continuity. If you export this mesh without tangents, since the vertices at UV continuity breaks will be saved as two different vertices, with the same normals (if the exporter is any good) but with two different UV coordinates. Then when you compute the tangents, you get this result. Most formats do not get exported with tangents. So problems abound. Ideally you would export normals, tangents and binormals, to make sure that the mesh looks identical in your renderer and the 3D modeling program. These bad tangents were the reason why I got the same problems with the rings across different XNA engines.

The first step was to get rid of the crappy computed values provided by XNA and compute my own:

The seam is still there of course. And it will remain while there is an UV continuity is there. It is about taking control away from XNA when generating tangents and taking over that. Special care can be had when modelling the mesh to avoid such problems, but it is not always possible. And I'm a programmer, not a modeler. So now I'm in control of the tangent generation. Let's improve this generation a little:

Tangents are now just a little bit smother. But besides the obvious seam, the tangents should be theoretically correct, so maybe they can help with my barrel ring normal mapping problem. Let's find out!



OK, take a look at those rings! I tested from different angles and the rings now extrude the right way. The tangents finally point the right way! I've had this problem for over a year without knowing it. Here is a closeup of the normal mapping with correct tangents:

The normals can still look a little bit weird, especially around the rings, where it seems that the wood is popping out, not the metal, but this is due to my poor auto-generated normal maps. With some proper normal maps, this can be fixed.

So let's see what we did. We fixed the tangent space and thus fixed the normal mapping issues. This has done nothing for the seams nor for the attenuation bug.

I have no idea how to fix the attenuation bug, but I write a code to detect the seams and a debug visualization mode to render the results:

This might look like the normal render of the tangents with the seams, but it actually highlights the seam that it detected procedurally. Now that I know where the seam is, I try to fix it. The fix is not 100% mathematically sound and I did pull some epsilon values in some comparisons straight out of my ass, but it seems to work just fine. I won't upload the full bunch of screenshots that I have, they can be found on the forum. The major very annoying seam is gone and I am left with a minor seam. Let's study this minor seam:

It can be seen if you look for it, but otherwise you probably won't notice it. The old seam was dire an immediately noticeable. But what causes it? Is it the textures that are not seamless or the fix is not good enough? Well, this is the corrected tangent view of the mesh:

Looks pretty smooth to me. Maybe in the future the seam fixing algorithm can do a better job, but I'm happy for now with it. Here is the same shot only with the normal mapping effect:

A minor seam, at least partially due to the texture work. And now the diffuse texture:

OK, I think it is clear that most of the seam is caused by the diffuse texture. If the diffuse texture and normal map get fixed, I think the seam will go away now that tangents are proper. I still need to test my algorithm on more complex meshes.

So to reiterate, fixing the tangent space fixed normal mapping direction, except on the seams. And now I fixed the seam. All imported meshes get their seams automatically corrected.

This is definitely the high point of graphics correctness in my engine! I'm looking forward to the day I'm done with the graphics once and for all.

But not today!

Another thing I tried is adding light shafts:

I based my implementation on J. Coluna's method, but I had to heavily modify it to get it to work and my results are not as good as his. Still, not bad. Even with that post and the working code in front of me, it took me almost 6 hours to get this thing to work.

So lighting is mostly fixed and we have light shafts. What next? I tried my hand at SSAO, but this one did not turn out that good:

It is dark, grainy, full of artifacts, there is an ugly fixed pattern on the screen that is very disturbing when moving the camera around and the distant lands look even worse.

I did try and fix this and came up with possibly the most ghetto ass SSAO implementation out there:

Needless to say, I don't like how it looks and I won't be including it in snapshot 6.

Thursday, August 15, 2013

105 – Fixing them bugs, but more

So I managed to fix the grass lighting bug with relative ease. I was right, I introduced it probably 30 minutes before doing the packaging. The grass response to terrain deformation bug might get fixed until Monday. I'm not sure yet because first I need to optimize that code a lot, because the bug fix implies doing some very slow stuff.

Still, I am on track. Snapshot 6 will be proper and will also finally have INI file saving. I also isolated all grass related features into a standalone class that is very easy to use. All you have to do is give it the terrain and in rest it will take care of loading, saving, responding to deformation, rendering, etc...

So let's talk about future engine features. The very next feature will be static persistence and a few new extra assets to persist. Finally, those trees and boulders will be available for map generation and you will also be able to place them, and once you do, they will be there next time you load up your save. This will be pretty easy, just need to optimize the old placement code, add some persistence and clear grass around the newly placed objects.

I'm not sure what the next step will be. With fully persistent maps, I could go heavy into map generation, adding about 20-30 assets and making the outside world interesting too look at first. After it is interesting to look at, it will need to become interesting to explore. Or I might delay this in favor of adding lakes, with buoyancy and ripples and reflective graphics. The third major candidate is random dungeons. I could create some very simple rectangle based assets and write a random dungeon generator. Later, a skilled 3D artist (or some hobo I can find who does 3D for food) could replace those rectangle shapes with a dungeon tile-set. It will work as long as you respect the alignment and join rules. The same basic tile-set could be skinned to create several different looking dungeon sets.

Too bad I don't have my old audience or traffic on the blog, we could hold a vote! I'm really excited about all 3 possibilities. OK, maybe not exactly excited about lakes, but I'll gladly do it.

Once this is done and we have a good over-world and good dungeons, maybe with lakes, we need path-finding and combat. And in the meantime, I'll be slowly adding skill implementations, new assets and new creation tools. The next creating tool will be a variable radius smooth tool. Have a rough terrain? Need to place some houses and make it more easy to traverse? Smooth it out on a large scale. The small scale editing tools work for this, but it can be fiddly to create a smooth terrain and takes some time. With the smooth tool, you'll just need a click.

These are all functionality related features. But how do I stand with graphics? Well:
  • Terrain: mostly done. Graphics wise I am happy. The only thing I might change is the blending of textures from close to far to reduce repeating patterns and maybe add support to a 5th or 6th material.
  • Grass: almost done. I need to update the generator to use all available grass textures, not just one and also make it that 1 in 10 or something like that bushlets use a weird color, just to break up the uniformity. A second grass texture might make it into Snapshot 6.
  • Lighting: on the right track. Terrain handles up to 10 point lights/cell and might raise it to 15. Grass handles up to 5/cell and might raise it to 10. Once I add the static geometry, each mesh should also handle 5/10 dynamic lights. Dynamic geometry will be harder to illuminate, but I'll handle it. There is still one nasty bug with point lights I can't figure out that makes me waste one extra shader output, so rendering 5/lights per mesh might require two passes.
  • Shadows: I'm not touching that with a ten foot pole. This is such an American expression. I have no idea how long a foot is. And I don't care. But I love poking stuff with poles. So anyway, I have wasted weeks trying to create good looking shadows. I believe past projects have died because of shadows. That's why I am not touching them. I won't even take the shadow mapping from an open source project. On the other hand, if somebody from those projects is willing to isolate the shadowing code and write some easy to set up components that I can try with ease, I will give it a try. I might have to find somebody and pay them for that. As long as I am not the one who is touching the shadows. This is a purely subjective and artificial requirement. I stubbornly refuse to waste more time with shadows and delay other good features for this cause.
  • Post-processing: well bloom is working round the clock. I believe snapshot 5 is more bloomy that the rest and I'll dial it back. I used to have more post-processing, like the black edges used in cell shading, but that is dead code. 

What? Dead code? In my engine? Can't stand for that! Let's fix it and enhance the post-processing pipeline for teh ultimate graphics! I'm not sure about the black borders, I don't think the fit well with my assets. What I really want is light shafts. Not a very physically based or expensive implementation, just some basic subtle ones. Then I would like to enhance my fog with a depth of field effect. I generally dislike DOF and turn it off in games, but I love the way Warframe does DOF. So I'll be trying to implement a DOF scheme where the focal plane is so set up that everything in front of you is focused and before one reaches the fog, everything becomes blurry. Finally, since we are at it, might add some SSAO.

Let's start with light shafts. Light shaft require a depth buffer to be rendered, but depth is boring and since other effects require a normal buffer to be rendered, we'll start with that.

My post-processing framework also expects these buffers, so let's write some fresh implementation for generating them and get rid of the dead code. First we fix and resurrect the secondary render targets and their display on screen:

The second render target is now the normal target. As you can see this target renders the scene again, but it filters some content. We don't want the skybox or grass. Grass is just some eye candy, it doesn't respond to physics and we don't want it cell shaded or influencing SSAO. With this filtering, the pipeline for generating these targets becomes simpler and faster. But we also want to strip out more, so we strip out all the lighting functionality from secondary render targets:

As you can see, while the regular scene is rendered fully, the normal target doesn't waste time with unimportant components, neither on the CPU or GPU. The lighting is only computed for the main scene. 

Finally, we replace the fairly expensive shaders use in the main target with a new set of shaders for the secondary target. For now, only a normal output shader:

Ignore the fact that colors are not scaled correctly to RGB range. I fixed this.

For some strange reason, I decided to not remove fog yet from the secondary render target pipeline:

I reduced fog offset to make it visible. I will probably remove fog from the pipeline though. The main reason for the screenshot is to show that I added the ability to inspect secondary targets in full screen mode.

Next, we add all the mobile meshes to the pipeline:

And replace the shaders they will use:

Ignore the small transparency bug. It is fixed. 

Now comes the real challenge. While most of the effects I need can use such a simple normal map, some might need real normal mapping:

This was very hard to do. In the past I failed to go from normal maps to such a scene where all normals are pointing the right way. It took me two hours to do this, most of it spent on studying tangent space transformation. And this was the key. The values you sampled from you normal map need to be converted to tangent space.

Terrain is not fully normal mapped because for now I don't need it. And while color blending is easy, I'm not sure how to blend the normals right now. 

Since we can render normals in two ways now, I add the possibility to switch on the fly which method is used. The simple method:

Or the one that samples the normal maps for objects:

Since I don't want to leave you with these screenshot that were done before all the bugfixes, here is a glorious shot of the final look of the normal target:

I think this is already paying off and might turn out to be a valuable debugging tool. Take a look at this screenshot:

Do you know how I'm always complaining that the rings on the barrel sometimes are "extruded" in the wrong direction? Well, those normal maps seem to be somehow changing direction from left to right. This might lead me to track down the problem finally.

So what next? Now that I have the normal target, I need to add the depth target. Then I will start working on the light shafts.

Tuesday, August 13, 2013

Tworenas Snapshot 005

Hey, another snapshot! Because of my vacation I am on a tight schedule and didn't have time to write normal posts, so this time you'll get just the snapshot announcement. Anyway, this snapshot is all over the place, so writing some dev blogs would have been quite hard.

I'll try and catch up with the normal Monday release schedule from next week.

So this snapshot has two major features: skill tree and better grass.

I started expanding on the skill tree (ignore the stock icons, I didn't bother to find too many or assign unique icons to each skill; I'm searching for a proper artist to draw them right now):

This is about half as much I have designed in my spreadsheets, so in the future it will scroll and zoom. And of course, most of it is not implemented yet. Tool-tips and descriptions are also M.I.A., but soon they should be available.

I am yet to explain my concepts for the skill tree, but you have several paths that you can advance upon and they all share a theme, like in this partially filled in skill tree:

Some of the skills are already implemented and I have most of the skill tree planned out, so it just a question of adding both the skills to the tree and implementing them one by one. Adding things to the skill tree was very cumbersome in the past, but now I have created this nifty skill editor:

This allows you to specify position, requirements and relations between skills on the fly. Changes in system mode reflect instantly upon the skill tree and while clicking a skill in game mode adds a skill point, clicking it in system mode will highlight that skill in the skill editor.

The second new feature is updated grass. I greatly optimized grass and implemented a complex pooling system, greatly improving memory allocation, freeing and management, while bypassing the C# GC, which still has the unwanted property of making my frame-rate random each time it triggers. Doing GC on a several MiBs large heap in a framerate based application where all frames must take roughly the same amount of time is impossible, so the GC must never trigger a lengthy collect phase. While memory behavior is great now, memory use is still a little bit too high. I'll fix this in a snapshot or two.

So now grass is smooth as butter. But what else? I wrote a new set of shaders just for grass. I went with a new illumination scheme, less physically based, but it looks generally better:

Now you can subtly distinguish the shape of the terrain underneath the grass by looking just at the grass. Here is another shot:

As an extra feature on top of this shading, grass now support coloring on a grass bushlet basis, but I did not do anything with it. But it is good to know that if you want to make a single grass bushlet red or something, there is support for that.

Another new feature is grass response to terrain deformation. Raising terrain or lowering it too much might remove grass bushlets to prevent them from overlapping/clipping though each other. This is right now slightly buggy and sometimes wonky.

Finally, grass now supports lighting, like the terrain does. It uses the same limited unlimited scheme, but this time with a maximum of 5 lights/cell. This might seem less than the terrain that supports 10, but since the cells are smaller, grass lighting actually is more flexible than terrain.

And here is the problem: I implemented it, tested it on a computer and it all seemed release ready, but on my other computer, the entire scheme is all messed up:

There are clear visual glitches with the grass lighting visible. I have no idea why it does not work on this computer and on how many computers it works, but it is far too late to try and fix it now since I am so late with the release. I apologize for this major bug, so feel free to skip this snapshot.

I hope that snapshot 6 will have this bug fixed. Oh well, I'm sure this is not the first time a bug will sneak in just before the release.

Since this release turned out so buggy, I won't do a video or give you a detailed changelog. The changelog might become invalidated by snapshots 6's changelog. So snapshot 6 will be a pure bug-fixing release and will arrive on time on Monday.


Link:  Snapshot 005

Wednesday, August 7, 2013

Tworenas Snapshot 004

Hey, I'm back from the seaside all tan and in already missing the waves, man! I had less time to pump out this snapshot so that's why it is late.

Here is a video showing off the new main feature of the the engine: terrain lighting!

One immediately notices that I'm tired after my vacation by the abnormally high spelling errors. Oh well, I'm not encoding and uploading again. I also did quite poorly on my new goal: have shorter videos. I need to find a way to make the videos 2 minutes long, not 5-7. Ain't nobody got time for that!

The video is fairly self explanatory, so I won't be repeating everything here. Just  note: I mention the 10 lights limit per cell in the spatial partitioning. This means that actually there are 9 dynamic lights you can place anywhere, because the 10th is you personal light. So basically 9 lights / cell. Also, the number 10 is not quite arbitrary, but is due to limitations in the shader model. I could raise it to 15, maybe even 20, but that will come with a good performance hit. We'll see.

For snapshot 005 I wanted to do a zero features 100% polish build and increment the version number, but I need to do something about the skill tree first, so the polish build is delayed to snapshot 007.

There are two things to take of note:
  • I try and make sure that there is zero regression with each new snapshot. THIS TIME I FAILED! The terrain shader is over 1200 lines long. There are a ton of permutations to handle the lighting scheme and I couldn't manage to update all 3 terrain quality settings, so for snapshot 004 only the "high" quality profile forks properly. Don't use "medium" or "low".
  • As usual for early snapshots, there is zero backwards compatibility. Even if you do manage to load a world from previous versions, there will be ugly bugs, so start with a fresh set of worlds. Things should settle after snapshot 010.


Link: Snapshot 004

  • Terrain lighting!
  • Grass frustum culling!
  • New terrain renderer class, with a lot better performance and new features.
  • Separate GUI manager class to reduce the code bloat and isolate the engine from the GUI.
  • INI file contains device settings! No more changing setting every time you load the engine! Settings are still not saved though. But now INI files support spaces in the format.

  • Fixed the transition from system hub to game mode, together with inter-spread focus changes form the device window. Again! This shit is so hard to fix.
  • If you run the executable from a random location where it can't find any resources, it will crash a little bit more gracefully. If it can find the bare minimum, it won't crash. Ideally, it shouldn't crash at all.