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.