This update contains not that much text which is good for you. Most work happended under the engine hood which is not that interesting to the outside world. This time around I had more ZPOC related experiments going on which produced a couple of bug and enhancement tickets to be added (bad for me as this means more work but good for you as these are problems fixed before the first release). Just read the descriptions in the videos ZPOC2 and ZPOC3 . Now on to to what is really important.
First things first I wrenched around in the shader system adding shader inclusion support. This helps me to make more optimized shaders with more abilities that are more stable and easier to maintain. The power of the skin system bases a lot on this system there. Nothing for the game developer to get in contact with but nevertheless a very important piece of software, without which all this magic (which in some parts could even beat AAA engines) would not exist.
Besides this I've added also a video texture property. This has been requested since the current system requires artists to rely on the coders to provide a dynamic skin with a video attached to it. In some cases though you just want to play a video or animation on a texture (for example a monitor) without requiring to deal with dynamic skins. This is now possible.
Furthermore I've modified the behavior of renderables. Up to now you had to choose between static property content (value, color, image, video) and a renderable. This imposed not required limitations. Now the two are separated. Every property can have now an optional renderable name assigned. The static content (value, color, image, video) is used until a dynamic skin is assigned to a component holding a renderable with the matching name. A renderable is now a true extension to a skin property. If dynamic content is present it overrules the static content. If not the static content is used. I've tested this system in the ZPOC using "zoid paints".
There have been also other smaller changes not worth nothing here. Now on to the big one.
SSS is a buzzword but getting it working is a problem. Papers about this topic are mixed and the results are mixed as well. I don't want to talk long about SSS since I'm sure many know what it is and what it helps so see the new absorption and absorption.range texture property for a description. As always I've spent time to figure out how to add simple and easy to use texture properties to handle this case. So I've reduced it to absorption and absorption.range to provide both SSS and translucency.
I've taken the liberity to use the algorithm from my SSAO implementation since I've noticed an interesting behavior it exposes. This behavior I used for the SSS implementation. This implementation allows me to do SSS and translucency with only one single shader pass with no multi-pass blurring or texture space blurring hacks as typically employed. Furthermore this implementation is physically inspired which means it's not just blur-without-a-reason and not just a pseudo-SSS as some recent AAA engines like to use. This especially means the SSS and translucency implementation used in the Drag[en]gine runs in average 0.25ms. This makes SSS and translucency rather cheap and usable everywhere it's of use. So I'll let you off the hook for now with some images.
And yes, the Stanford test models (dragon, armadillo, buddha) are included in the editor so you can easily and quickly test your materials with them.
More tickets to work down. Next tickets are about the game editor. All in all working off more tickets.
Windows in games is a huge problem. They are always done by using a flat texture on facade meshes. This results in flat looking facades which break the credibility of the world. The Drag[en]gine provides an interesting solution to this problem to spice up your game world without adding extra geometry or making things complicated. But first things first...
Besides bug fixing tickets one topic has been texture preloading. Loading textures is one of the most time consuming processes and different drivers can yield vastly different results. The most simple solution is to upload a texture base level and let the driver compress and mip-map the texture while uploading. This happens synchronously and can take from a second up to a lot of seconds with large textures. Also the quality of drivers compressing texture varies a lot. One of the tasks had been to solve this speed and quality problem. The mip map calculation and texture compressing has been moved now into CPU land. While loading textures asynchronously they are now mip mapped and compressed on the CPU before being uploading synchronously to the GPU. The performance is totally something else. Previously loading the game world took up to half a minute on certain drivers. With the new loading routine the loading of the game world takes only a few seconds now. Furthermore texture compression quality is now stable and fast no matter what GPU and driver you are using.
In between I took also a couple of days off to tackle a proof of concept side project. I use this to test certain engine features I can not test with the main game project. In this case I took a stab on that Shield Liger model I had around. I create the project files from scratch and whipped up a first working prototype in a couple of days. While working well this showed me where I still have to apply changes before the first engine version is released and I found bugs I fixed I didn't come across in the main game project. Last but not least this gives a little off-topic video to look at: YouTube Video.
No, I'm not going to end up like those wannabe game-devs filling up their news posts with totally irrelevant videos of their dog, bed room and weather outside just to rake in PR although there is nothing worthwhile to talk about to begin with. I'm talking about rooms behind flat walls.
As mentioned in the intro this update deals with the problem of flat windows. Some years ago I came across a nice article on the Internet of a clever guy who had a clever idea. For some strange reason I've not seen a single AAA game-dev picking up that idea although it's cooler than a polar bear in a freezer. In short he replaced the flat texture with a cube map. Taking that basic idea I wrapped up a working solution which is as simple to use as anything else in the Drag[en]gine.
For this purpose new texture properties had been added:
The next tickets to work off are a bit more technical so the next news post most likely will take a bit longer since technical stuff doesn't show much with videos or images. The close goal is still the first engine release. Working off tickets is still coming along nicely.
Using plugins usually ends up with limited engine access. This is not what I wanted for the Drag[en]gine. Thus I've implemented a plugin system which does not only place the engine in the website but gives you control over it.
Load installed Drag[en]gine , modules and installed games
Sets up the engine using found launcher configurations on your computer
Checks all game requirements are fulfilled
Provides support to launch an installed game
Cleaning up the engine after exiting a game
The provided launcher functionality works similar to the console and GUI launcher installed by the Drag[en]gine. You can thus use the plugin to simply play games through your browser window or (and this is more interesting) to play games straight from the web. You can simply fill the engine with resources from the web and start it up with a Web-Game profile. This way you can make a game with web-content but using the installed Drag[en]gine for maximum performance and compatibility. The same platform independence holds true for the Drag[en]gine between the Web and PC like between PCs.
Creating a game for PC makes it automatically work on the Web and vice-versa with NO extra work, NO recompilation, NO repacking and NO second versions to manage.
Now is time for some more remaining ticket reduction work. Let's see what the next news post holds in store for you.
In the last news post AniCator asked for ambient occlusion for the cloudy day system. First things first the Drag[en]gine knows already texture defined ambient occlusion using the ambient.occlusion texture property. You can generate these using Blender3D for example. Since he asked though if dynamic ambient occlusion would be possible I took a little side-step to plug this into the engine.
Dynamic ambient occlusion is something game developers like to use since some time. You can plug those in as a post-processing effect and get done with it. Unfortunately most implementations found so far in games are crappy. I do not wanted to have crappy SSAO in the game. Better no SSAO than crappy one. So I dug around recent implementations evaluating their usefullness (and/or crapiness) with my own modification idea in mind. As it turns out somebody else had a similar idea just recently which is usually a good sign if two minds come up with the same idea. The implementation sails under the name of Scalable Ambient Occlusion or SAO for short. The basic implementation is nice and is screen resolution and depth resistent with constant cost but suffers from some math which likes to produce the dark halos as mentioned in the article above. Altering the math a bit though with a more "sane" mathematical background helps to reduce the problem. Removing black halos though tends to introduce white halos but these should be less problematic.
Cheap implementations plug SSAO in as a post-processing effect messing with all lighting. This is utterly wrong and is another source of bad results. In the Drag[en]gine the ambient occlusion (both texture and dynamic) affects only the ambient lighting. The direct lighting is not "directly" affected but more about this later.
So here first some images of the SAO in action. The shadow areas receive subtle occlusion effects. Over-done SSAO looks crap so the goal has been to have physically plausible ambient oclcusion instead.
And here a test video showing first the pure ambient occlusion texture and then some sample location s with SSAO enbled and disabled. At the end you can also see how the effect does not affect geometry in plain sun light but only in shadows.
With a little extra line of code in the shader the ambient occlusion can be used also to provide a form of limited self-shadow casting. The Drag[en]gine limits this to texture ambient occlusion only since this AO is of higher quality and of smaller scale. This shows the result.
And here a video with a turning light source. The self-shadowed version is a subtle enhancement of the shape perception with the advantage of having no additional cost (no cone-stepping required). As such though the method has it's limits.
There's room for improvements with this entire SSAO stuff but right now it is more important to work off more of the remaining tickets for the first release.
This year everything went somehow different than planed in the first place, for the worse or the better. Besides hardware issues some tasks had been so large and intertwined that making a news post earlier had been tricky. Besides that I also didn't feel like making a news post in the last couple of month. Whatever the reasons out of the work done these tasks had been the most time consuming and important ones.
The main focus had been on reworking the shader system to lift it up to the next level. This had been unfortunately required to get all the bells and whistles done I've planed for this project. This included skin and lighting shaders. This took quite some time since the shader system in the Drag[en]gine is deeply integrated for versatility and performance reasons. Also decal rendering masks have been improved to allow more natural decals (see puddle image).
Another focus had been on optimizing rendering and lighting on various ends to increase performance where possible. This took also longer than expected.
An unfortunate focus had been on upgrading my entire PC leaving me with nearly 2 month of no chance to work on the project. Never before an upgrade went so TARFU. At last the HD7970 is now humming alongside the QuadCore as it should except I'm only running at 75% possible performance but the upcoming driver upgrade should fix this (hopefully).
The last huge task involved redesigning the reflection system. I've evaluated and test-implemented various reflection approaches from simple env-map blending to local reflections to find a good system which actually works with Physically Based Rendering. The system in place now works with a combination of global and local reflections with distance roughness, optional projection boxes and optional mask boxes. This all works across all geometry types in the engine without any additional work by the developer.
Eventually a first version of a weather system has been added to the game to test the reflection system.
This is only the most important part of all the work done. The rest is included as the typical bullet list at the end of the news post to not scare away people with a huge text wall. To counter the text here a few images and some test videos. To not spam only the first of the images in both profiles are linked. Find the rest in the respective gallery going to the left ([u]15 images in total[/u]).
Here a small video of the reflection system in action. I think images work better but sometimes people like more something that moves. So here all put together (video-grab messed up the colors).
And here something for the lovers of details. The new weather system also includes cloudy weather code. You all know how lighting conditions change quickly if clouds pass by the sun on a cloudy day. This code uses the Drag[en]gine Sky System to simulate this effect. Since in a detective game locations (sets) are important I would like to add some effects to them like this one here. Watch the entire video to see it. Other weather conditions will be added like foggy or soft/heavy rain to make revisiting locations more interesting.
Although during this year work has been slower than anticipated the number of task tickets left for the first release got less. The end is not far away if nothing else breaks right before the end. With these interwined tasks out of the door news posts will be more frequent than they have been up to now.
Here the very short list of what happened during all this time. You can stop reading here if you don't want to know all the lengthy details.