Location: Main

Twitter channel online

Drag[en]ginePosted Mon 29th Jun 2015 at 13:26:59 by Dragonlord Authorized by Dragonlord

Twitter Channel Online

You can now not only track the game engine and game project on the Drag[en]gine and Epsylon profiles, you can now also track it on the EpsylonGame Twitter Channel.

So if you want to support the love for this project tell your friends about this channel or re-tweet what you find there. Every support helps.

Getting up to Speed with all new good things and Game-Dev Docs

Drag[en]ginePosted Mon 29th Jun 2015 at 13:24:18 by Dragonlord Authorized by Dragonlord

Can you say Work-Tech-Aholic?

These past month had been fully in the name of performance improvements, feature adding and especially documentation. I don't go into much text here since the documentation part is where the big huge text is located for those interested in both the inner engine workings and especially how to developer with this game engine. This produced lots of documentation especially for the DragonScript language in form of API documentation and Wiki documentation. Now included is also the first demo application for the new features. More will follow to get you started with the game engine. But from the technical point of view what ate the majority of time had been a tremendous performance improvement workover that touched many engine areas. Various performance improvements including Parallel Processing and an advanced OpenGL render thread system consumed more time than expected but the result is a total performance boost of up to 150% over nominal this spring. There is still some room left especially in foreign code not that much under my control. And if this would be not enough already the Drag[en]gine has now also a whole new Canvas System. So before the Links to all the information a little view across some of the parts touched during the past time.


Speed optimizations


  • Optimized Bullet Physics calculations (certain Bullet collision tests are slow and inaccurate).
  • Optimized matrix and quaternion calculations for CPU code.
  • Animation pre-calculation for animation resources (pre-canned animation data).
  • Post physics collision test to colliders improving performance and simplify typical test scenarios.
  • Parallel processing implementation.
  • Animator calculation performance boosted with parallel processing.
  • Multi-Threaded Rendering in OpenGL module with optimal synching. No restriction on what game scripts are allowed to change ( 100% autonomous render thread ).

New Engine Features

  • Collision filtering with filter and category layer masks (64-bit each).
  • 2D Render System with improved video playback and canvas capturing.
  • Bullet supports now collider rotate hits and collider move rotate hits natively.
  • Engine module version support to launchers allowing for multiple module versions to be installed at the same time and barring certain versions for certain games.
  • Improving animator editor usage (rule icons, group rule support and cut/copy/paste in more places)
  • Collider attachments support now all kinds of resources.
  • Smooth value support especially for script use with natural smoothing behavior with unpredictable values.
  • Barrier and proper sempahore implementation.

New DragonScript Features

Show it to me!

As you noticed there is no big content update. Since I had been all occupied with all the tech and documentation and I still have no helping hand except myself I could not also deal with content. So if you are from the artistic domain and you want to do something else than what is usually around you are welcome to step forward. No portfolio fillers. I had enough bad experiences with those.So happy game-deving until the next time.

Beam me up Scotty!

Drag[en]ginePosted Thu 24th Apr 2014 at 23:21:37 by Dragonlord Authorized by Dragonlord

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.

Particle Beam Simulation

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

The Various Ticket Topic

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.
Transparent SSS


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.

Outlook

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 goes under the skin

Drag[en]ginePosted Sun 30th Mar 2014 at 20:10:36 by Dragonlord Authorized by Dragonlord

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.

Skin system enhancement

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.

Sub Surface Scattering and Translucency

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.

Outlook

More tickets to work down. Next tickets are about the game editor. All in all working off more tickets.

Insight into my compressed room

Drag[en]ginePosted Sun 16th Feb 2014 at 1:13:58 by Dragonlord Authorized by Dragonlord

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...

Preloading CPU Mip-Map and Compression

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.

Meanwhile in Zi...

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.

Wanna see my room?

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:


If you want the details have a look at the linked wiki pages. In short this allows to specify an environment map type cube map to simulate a fake room behind the flat window mesh the texture is applied to. The texture coordinates of the unwrapped window and environmentroom.size define the size and orientation of the room. The cube texture coordinates are calculated in a way the fake room appears under the right angle while looking at it from different angles. This gives the impression there is a room behind a window instead of a flat texture.

The video below gives an impression on how this looks like comparing the conventional flat window texture with the environment room texture on the same flat wall: ModDB Video

Fake rooms combine with other texture properties. They sort of replace the color texture property with a simulation of a rectangular room. Otherwise normal, reflectivity and roughness still work the same allowing to have window glass reflections while looking into the room. All this without touching shaders at all nor trying to get all tangled up with shader node systems.

Outlook

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.