This time around a lot of wrench work in the engine core parts has been done not translating well into a news post. Nevertheless some parts of it are interesting namely the beam particle simulation, particle lighting and various other improvemnts along the way. I'll keep the talk short and give more time to a video.
So far the particle and ribbon simulation mode has been full working for particle emitters. Beams had been not full implemented so this changed now. Particle emitters with beam simulation mode allow for a lot of possible effects. I'm not going to talk about them but show some examples connected with the changes in the video. In a nutshell you get ribbon like beam rendering with physically simulated particle path. Animated path is topic I'll talk about in another news post. Sheet rendering for ribbons/beams has been improved. It's now enabled by default. Particle light sources have been fixed and improved. Every emissive particle, ribbon or beam casts light automatically with the same complex light shader as all other light sources. Added beam curve for burst beam lifetime control. Also added particle warm-up time to get emitters starting in full beauty on enabling casting. Last but not least fixed a leak problem with particle emitters generated automatically on particle collision.
So here is the video with some examples.
ModDB Video, YouTube Video
Other stuff is not worth a full section but important nevertheless. SSS is now improved for transparent objects. Allows for properly damaged glass for example as in this test.
Furthermore upgraded to Bullet Physics 2.82. In the same time fixed some long standing issues with Bullet Physics. Also reworked the DOF for constraints adding support to implement static and kinematic join friction and breaking force on Bullet. Not working yet since bullet has some own ideas about certain things I need to re-implement first.
On the IGDE editors various cleanups have been applied I came across on my way to make the first release quicker (as it's done already).
Added animation scaling support. It had been broken in the export scripts. Scaling can be applied anywhere in an animator but care should be taken since physics modules might have troubles with strangely scaled colliders. Here an example shot.
In the OpenGL module I switched code over to use Texture Sampler Objects. This helps with keeping complex rendering maintainable and saved state change calls.
And to wrap it up the curve editor in the particle emitter editor received some additional menu operations to speed up some common tasks.
I've promised some editor usage videos. I'll make them next and present them as an article for those interested in learning about how the editors work as well as those interested in giving early feedback to incorporate until the first release.
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.