On the Graphic side more shaders have been converted to proper GLSL 1.3 . Only a few shaders are missing and then the conversion process is done for. Furthermore a new render mode has been added inspired by UT3, the half-render mode. If this mode is enabled the game is rendered to a render target of half the screen size. During the finalization processing the rendered image is upscaled to the real screen size. This helps weaker machines as rendering takes place on only 1/4 of the screen size. The quality is not as good as rendering to the full screen from the beginning but this allows to improve render speed on machines where otherwise the render speed would be too low to be acceptable.
On behalf of the Rig Editor constraint visualization has been added. This had been missing since quite some time and is a rather important tool to judge how the outcome of a constraint attemp is going to be. Currently linear and angular limits are shown as in the image below. Furthermore rig constraints obtained an own class different from the collider constraints which helps with Rig Resources in the long run.
So far the Drag[en]gine had conventional rigid body physics using rigid constraints. For rigid bodies this works to some extend but dynamic objects like dragon wings for example cause troubles and can not be done well. Now the engine supports spring parameters on all constraints. Using springs the retention forces on a dynamic object like wings can be simulated to some degree. The wing web on a spread ( or unfolded ) wing is under tension. This is one of the important properties to enabled flight. Without muscle force applied the wing web tends to pull together to a non-tension state ( physical principle of the least energy ). To achieve this behavior the wings have been constrainted using a combination of rigid and spring constraints. This is only the first version but it can be improved upon. The image below shows the setup of the dragon wing. The constraints ( in purple ) along the wing finger and the wing web are rigid constraints. The constraints perpendicular to them are the spring constraints.
Some earlier testing videos can be found on here: Dragon Rag-Doll Test 2 ( with spring-wings ). Furthermore below a video where everything has been put together: Dragon Locomotion, Ragdoll Physics and Spring-Wing physics ( also on youtube: In-Game Dragon Locomotion Testing). The first sequence shows the dragon locomotion with body tilting and feet-on-ground animator test. One of the strength of the Drag[en]gine is the Animator system which allows very sophisticated animations with ease. Especially multiple animators can be used. In this example two animators are used both loaded from files so you can mod them easily.
The first one does the animation of the actor. The second does the aligning of the feet with the ground. One of the advantages of this system is that the second animator is optional. Should speed become an issue you can simply not use it. Animations become this way pluggable/moddable in a way you can't do it with other game engines. The second sequence shows the same as the first one but from the eye-camera. Here it can be seen well that using the dragon locomotion with body tilting your view stays exactly where you want it resulting in a smooth camera motion. The only issue right now is with the chase camera. It faces always where the actor is looking at but due to the up and down this can be a bit cumbersome. The camera class will be modified to counter this effect later on.
The third sequence shows the ragdoll ( or how I call it a dragdoll ) with spring-wing in action on a slopy mountain side. Still some issues with the Bullet Physics library and collision objects falling through the ground. Erwin wants to add CCD ( Continuous Collision Detection ) back into Bullet at some time but this is still future music so far [ I have to come up with a hack to counter this problem until this time comes. That although is not a concern for game devers using this engine but my problem... *gasp* ]. The fourth sequence is again the same as the third one but using the eye-camera. Important to note for those not knowing about "Dragon View Mode" yet. This simulates how a dragon sees the world using two views one for each eye. Instead of 90 degrees as with common game characters you see 180 degrees. Hence you can manage to see your body rotating your head sidewards strong enough.
In-Game Dragon Locomotion Testing
Now comes something a bit more technical but very important. A game with graphics and physics is nice but without game mechanics it's useless. Many projects forget about this until the very end and then it ends in a coder nightmare. The Drag[en]gine on the other hand has been designed from the very beginning with a sophisticated and flexible game logic system in mind. Recently I collapsed some classes together to improve the system but first an image and then some explanations.
This looks now a bit menacing but it's rather simple and nifty. On the right side there is the Actor class. It's one of the element classes in the game. Actors as the name state describes any kind of object which acts on their own or using the help of a player. Each element class has some per-frame-update methods called by the game as depicted by the arrow. Elements are made to "think" which tells them to act in one way or the other. Once done "postThink" is called once the entire world has thought about their next move. This is for example is the place where the feet-on-ground animator mentioned above is used. So far this is the way conventional games handle the processing. This is though also not very flexible. Now enter the Drag[en]gine.
Each Actor has one ActorAction object assigned. The Actor forwards the frame-update messages to the action object which in turn handles the acting for the hosting Actor. This allows to add specialized subclasses as in the example the AIAction and the PlayerAction which both are subclasses of the ActorAction. The AIAction object uses AI scripts and objects to figure out what to do. The nice part on this system is that you can modify the AI objects or even assigning a different AIAction object altogether to change AI behavior on the fly. AI becomes now pluggable/moddable like a LEGO system which allows to create complex AIs ( more about that in the upcoming Epsylon news post about the Knowledge System ). On the other side there is the PlayerAction object which takes input from a player and acts accordingly. Here again complex interactions with the game world can be broken down into small units. For example in the Epsylon game handling different objects is represented with individual subclasses: SDEmptyHand, SDThunderpad and others. Changing the behavior of the player is as simple as switching the PlayerAction object. You can now work precisely on specific player interactions without distrubing other interactions. Furthermore you can subclass player interactions to specialize and improve them. For example pushing buttons is done using SDInteractiveButtonPanel which provides the interaction. Two subclasses ( SDKeyPad, SDElevatorPanel ) provide then the specialized behavior for using a security key pad or an elevator button panel. The result is more robust scripts code which is also faster to write and simpler to maintain.
Now how to get the input to the player? Hard code it? No, this would be bad but unfortunately often done in games. The Drag[en]gine places there another nifty layer in between, the input processors. When a player issues an input like pressing a key on the keyboard an input event is generated which travels to the game scripts. There the event is handled by the current InputProcessor object. Again this allows to simply switch input actions without a lot of coding work. The BindingInputProcessor for example takes the input and matches it against a list of Command objects. Commands define a key the respond to and specify actions for pressing and releasing the key. For example the MoveForward command would cause the player to start moving forward if a button is pressed or stops when released. It's the command which actually inveracts with the PlayerAction object currently set to the active player Actor object. This separates the input processing from the player interaction again improving robustness and maintainance.
As a second input processor exists the DesktopInputProcessor. This one is used to handle computers in the game. It simply takes the input and forwards it as it is to a Desktop object. Desktop objects are subclasses of the Widget class and are GUI components. Computers are nothing but GUI components with a Desktop as their root. The output is simple rendered to a texture instead of the screen. In-Game menus or all other kinds of game menus are also handled using a DesktopInputProcessor as they are nothing but a Window object located on a Desktop ( one desktop used for all in-game menus and so forth ). Switching between handling a player, handling a computer, handling the menu or anything else is just a matter of switching the current InputProcessor object.
This had been now a bit much of text but hopefully it gives an idea of how the Drag[en]gine Game Logic System works and why it is something to look forward to.
If you want to show your support and interest in this game engine as well as the attached game project you have to go to the Epsylon project page to place your vote since you can not vote for a game engine. The Epsylon project receives scarcely news posts and media updates since nearly all of them go to the game engine project page. It is always a bit of a problem where to place the news posts or media since the two projects are entangled.
Currently work goes on with the Knowledge System of the Epsylon project. It's something very exciting so I don't want to waste too much word about it right now. So please be patient until more will be revealed.
Tackled two nasty problems which nagged us for quite some time about robust shadow casting and getting dragons to walk.
The time constraints imposed due to the recent events ( last news post ) are more severe than expected. Coming by free time is very hard so it has been a fight by itself to get progress done. But eventually it happened and two of the more nasty problems have been solved. But like always first things first.
In the last time the editors got some code work and clean up done. Due to the way the handling of editing changed some time ago some editors still had been written with a different coding style and others. One effort had been to rework code parts and cleaning them up to get the editors on par in how they are written and behave. This also included adjusting controls schemes and UI to match up. A lot of time went out of the window though hunting down memory bugs which especially had been caused by bugs in the ATI driver. A work-around has been put in place to prevent this bug from leaking your machine.
So far for semi point lights ( 180 degree point lights ) we used Paraboloid Shadow Mapping. While working we experienced always a problem with bending which stems from a shortcoming in the technique itself. I came then up with an idea which should help remedy the problem while keeping us from using/wasting cube shadow mapping which I called Pyramid Shadow Mapping. I put up a small article talking about the technique. Down to the point this technique is based on 2D-Texture shadow mapping allowing us to use all the various shadow casting algorithms around which would be a problem with Cube-Texture shadow mapping. Besides the loss in speed compared to paraboloid shadow mapping is outweight by the better quality and higher stability ( besides not requiring an expensive tesselation step ). Here are two images showing the results. The first one is the shadow map itself rendered to the screen ( hence a bit blurred ) and the second one the actual shadowing.
[images]
Using this technique semi point lights can now be done easily especially fully dynamic ones. Now the last light source to fix is the full point light which has left some ATI driver issues
( introduced some driver revisions ago... grrr! >.=.< )
Something often required in games is touching the ground with the actors feet or touching some other objects. Inverse Kinematics is the known solution to this problem but as easy as it sounds as problematic is it to get an engine to handle it properly. This engine is designed from the ground up to support such complex animation situations without requiring too much leg work. For this the Inverse Kinematic animator rule has been modified to properly support various kinds of usage scenarios. New properties have been added, old ones renamed to be more sound and new controller targets added. The only problem left is the actual IK algorithm. It's a CCD but somehow it produces awkward results in some situations. I'm still looking into improving this. Since it's though in a module it can be fixed/improved any time without a problem.
The IK rule alone though is not enough. Especially for keeping feet on the ground it requires a lot of code work to get it done and the main idea behind this engine is to move the workload onto modules where possible to free game developers from dealing with such nasty things. For this a new animator rule has been added, the Touch Ground rule. This rule in general takes a list of bones and projects them down to a plane defined by a position and normal. This can be for example the ground or some wall you want an object to stick to. In addition a touch sensor and collider can be specified. In this case the rule projects the bones down to the nearest world geometry using the collider as the shape of the bone. Together with clever rig setups it is rather easy to keep objects down to the ground this way. There is still some code work required but nitting together advanced animations is now simple.
Getting a dragon to work properly in a game is a nightmare. Most probably the reason why no game exists yet with full 3D rendering, first person view and having sound and properly animated dragons. Main problem is the 4-legged nature of them. How to deal with 2-Legged actors is well known but when it gets to 4-legged the problems start. One solution is to simply tilt an actor on the middle of the body. If you use though a first person camera the player gets nausea. Besides it looks like the player is riding a roller coaster. To achieve better results the locomotion system has been altered to support 4 leg rigs. To deal with the feet touching the ground a split setup has been designed which is more flexible. Hence you can continue to use an animator to produce the animations you want. In addition though now a second animator is used which only contains IK/TouchGround rules to project the feet down to the ground. This second animator is applied after all the physics have been done. Therefore the system looks like this:
Apply-First-Animator => Physics-System-Run => Apply-Second-Animator => Render-Scene
The second animator is therefore optional and can be neglected. This can be useful if you don't have complex world geometry and the extra work is not worth it or for using Animation-LODing. IK rules are iterative by nature and cost processing time. In the distance you do not really notice if feet are stuck in geometry or floating in the air. Hence if you use a lot of characters with such a setup you can simply avoid applying the second animator if the object is too far away saving valuable processing time.
This sample video shows the current system which still requires some improvements. One note about the use of the touch ground rule here. The animation as created in blender features for each leg two bones, an IK base and an IK target with the later parent to the former. The IK base is projected down to the ground. This has an interesting effect. In blender you can animate like you did before but you constraint the base to the ground and the target to the feet. Hence the target stores the actual position relative to the ground as defined by the base. Therefore instead of trying to figure out where the IK target for the foot has to be programmatically it is encoded in the animation itself. You only have to adjust the IK base to the ground level to carry over the animation. The reason for this is that we want the animations to stay as the animator produced them. Using conventional IK systems the animation is destroyed since you need to figure out programmatically how much to lift the foot and where to move it. All these calculations are not needed using this system.
There is no IK rule used on purpose to stick the IK base for a foot to the ground when it touches it. This is a problem with how players tend to rotate their actors. Usually they fling them around quickly using their mouse. Using an IK stuck to the world position of the contact point would cause ugly twisting and twiching. Hence there had been only two solutions for this problem. Either you restrict the movement abilities of the player to avoid him twisting out his legs or you just project the legs down not snapping them to the contact point. We have chosen the second solution since this way the player is unrestricted in the rotation motion he can inflict. With the restrictions controling the dragon feels sticky like driving a car which is ugly. If the controls are annoying then the game itself is annoying no matter if the graphics/animations would be fixed with it. Therefore we choose responsive controls over accurate animation. You can see this in the second part of the video.
[video]
The rig editor also received some improvements besides cleanup work and adjusting the coding style. The physics simulation part has been improved to apply pushes on the object by shift-clicking as well as picking and dragging body parts around by clicking. In addition the handling of kinematic bones in conjunction with dynamic bones has been improved. This is demonstrated quickly in a video with a lamp hanging from the ceiling. The physics module also calculates properly the linear and angular velocities for kinematic bones hence you can just apply an animation and the physics module does the rest.
[video]
Some might not know what Haiku or rather Haiku-OS is. Back in the old times a company named Be made an OS and a computer much like Apple did with the macintosh. The OS had been named BeOS and the computer BeBox. It didn't go down well so the company went out of business and sold the rights. Offsprings are known then under the name of YellowTab or Zeta. A community project tries ever since to bring the BeOS back. First named OpenBeOS (OBOS) and now Haiku-OS ( or just Haiku for short ). Since the first Alpha version of Haiku hit the internet some weeks ago I went ahead to test my engine on this OS. As expected due to my crossplatform coding most of the modules compiled out of the box. It's not fully running yet since FOX-ToolKit does not exist on Haiku yet ( and the editors require it ) but all other modules except the Graphic Module ( no 3D accel yet for new cards on BeOS and no down-scaled OpenGL module in the engine yet ) do work. Hence as a game server it would already work :D . We'll get this engine fully running on BeOS for sure just because it is an interesting OS to fiddle around with. If you never tried it out grab the Alpha Image and run it in VirtualBox or something alike to get a taste.
The browser in the world editor received some improvements. You can now directly apply skins to explicite terrain textures besides others. Concerning rig resources in the engine a change has been made to allow unnamed rigs. This allows game developers to produce rig resources in memory instead of loading them from disk. A game like Spore for example would find this useful. Eventually the debug drawers have been improved in their handling. DDs are used by editors or for debugging purpose by either modules or even a game developer if required.
Last time we talked about a Special. Unfortunately due to the various things that got worked on as mentioned in this news post the Special is going to be delayed to the next news post. Don't worry though as it is already in the works. Doing this though showed some problems which had to be tackled first before the video can come together. So stay tuned for the next news post.
The update this time has been delayed by a significant time especially due to personal reasons which We're not going to talk about further here. See the blog post for more informations ( will be deleted 1 week later ). But no matter what hard blows smack you down you have to keep going and we keep on working on this project. Eventually we got around to put together another news post with informations about what is going on. And here it goes in no particular order.
Culling is always a hard job and especially in the Drag[en]gine with the open design aggressive culling is required to keep the frame rates at an acceptable level. Many engines can only handle one scene type well either indoors or outdoors but not well both at the same time. The Drag[en]gine has though the goal to seamlessly blend outdoors and indoors scenes without transitions or other hacks. For this more culling tricks have been mustered up improving indoor rendering a great deal. The improved culling removes outdoor scenery a lot more aggressive than before. You can therefore place highly occluded indoor scenes next into detailed outdoor scenes without slowing down. The transition areas are still a bit more tricky but we keep working on it.
Decals have been part of the Drag[en]gine since quite some time now but handling them in the world editor has been a chore so far. This has been now remedied by reworking the decal system on the level of the game. Like many other parts the decals are handled on two levels. On the engine level the decal support stays the same as before. On the level of the game scripts as well as the world editor the system has been changed. Now decals are world placeable objects. This makes them easier to use since they now automatically spawn across all the faces in their area of effect not just one particular terrain element. For this the editing mode has been changed as you can see in the image below. Decals are now handled like any other object with a position, orientation and size. The decal is automatically projected by the Graphic and Physics Module onto the geometry below they way the can use it best. While adding decals they align automatically with the surface below or you can force them to face to the camera pressing the shift key. Furthermore while moving decals you can press the control key to keep them sticking on the underlaying surface. This way of handling decals is better suited than surface oriented techniques since in the Drag[en]gine terrains are allowed to have holes and inside holes surface oriented techniques fail to work. This system here does work always.
Improved Decals Support
Object dropping by itself is nothing new but not every editor has a usable implementation for this task which can be a nuisance. The World Editor now supports dropping multipe objects on the ground below. While doing so any terrain element or object in the scene serves as surface to drop upon. As an additional twist automatic stacking is supported. Dropping multiple objects residing above or below each other stacks them properly while dropping them to the ground. Creating scenes with a lot of stuff littering around on the ground is very easy this way. Certain object classes act as ghost objects so they will not get objects stacked on top of themselves. Physical dropping will be added later on. The image below shows the new system in action.
Object Dropping
In addition the adding of objects has been improved. Using a separate Add Mode objects can be placed in the scene by simply clicking on the right spot. Objects are then placed where the ray through the clicked at point intersects terrain geometry or other objects. Furthermore pressing shift while clicking aligns the object with the hit surface which can be pointing anyways including downwards to stick objects to the ceiling or walls. You can also duplicate already created objects to quickly fill a scene with props.
So far the world editor had a textual element browsing feature. Since though many requested a graphical browser we mustered up some time to do a proper and useful graphical browsing. The main goal in the IGDE is not to be a graphical monster like some AAA editors are but to be professional meaning with a clean UI designed for fast and efficient working. After all huge graphics can't make your mapping live easier but a clever UI can. One major design guideline to achieve this goal is to use native OS resources where possible for the UI instead of rendering everything with the game engine. This allows mappers to work with their native OS UI instead of having to deal with often chaotic game engine UIs which are inadequate for efficient editing.
The new graphical browser follows this guidelines and uses native OS tools but combines them with engine rendering. The preview of the individual elements is rendered using the game engine itself which is easy to do since the Drag[en]gine supports multiple worlds rendered and manipulated at the same time. The result is cached on disk once rendered. Therefore you do not have to pack preview images into your game SDK blowing up the file size as the preview is build dynamically on the mappers computer on demand. Multiple preview resolutions are supported including the old text only listing for those looking for efficiency. In contrary to the dialog based text browser the new graphical browser sits now in the side panel alongside the other editing panels embedding it neatly into the overall workflow.
Currently the browser supports showing Object Classes, Terrains, Skins, Skies and Decals. The same filtering possibilities as with the dialog based browser can be used. Hence you can filter objects by selecting a category or filtering them by selecting from a list of tags. Especially the tags based filtering is very powerful since you do not have to know which category an element resides in but only its traits. The image below shows the new browser in action with a few states.
New Graphical Browser
The browser can be used in various ways. Double clicking on an element assigns this to the current selection. To add new objects of a given type just switch to the Add Mode and click into the world. An object with the class of the selection in the browser is added. You can also right click on an element in the browser to obtain a list of actions you can do with this type of element. This allows also to edit it in another editor once this feature is fully implemented. All in all this graphical browser is a very powerful tool. If you know something which other browsers can do which you think is important let us know so we can add it. After all we do this product for you, the mappers out there, not for our piggy bank ;)
There are always smaller changes which are not worth an own topic or even a news post itself so they get grouped here. The Semi Point Lights obtained a few tweaks to make them fully usable now. They can be now oriented into any direction as well as their shadow parameters tweaked. On the code side a first code clean-up batch has been done to get more code into a releasable shape. With the first release the code will not stop from evolving but at some places there are still code relicts lingering around.
Good stuff is ahead of you. We decided to make a Special for the next news post if everything goes according to plans. The idea is to cook up a demonstration world showcasing the features of the engine where possible. This will be recorded into a video for your viewing an informational pleasure. So stay tuned for the next news post.
A lot of time passed since the last news post but this is because a lot of stuff happened. Main focus this time has been on Out-Door Scenes.
This update took a bit longer than expected which is due to the fact that all the changes made recently had been correlated and showing the progress in between would not have done the situation justice. Therefore now a wave of updates so get your swimming gears ready.
A couple of smaller tasks had to be done to prepare for the upcoming batch of updates. Amongst others the asynchronous loading has been reworked removing a couple of problems. Furthermore the project has switched the build system from Autotools to SCons. One reason is that SCons scales much better with larger projects ( and this one is large, and I really mean large ) and supports Windows builds without many changes on the build system which Autotools simply is unable to. Also the Blender3D export scripts have been improved especially in the area of animation exporting. The changes are mostly geared towards making changes on art assets easier to improve prototyping.
The first batch of work dealt with the height terrain system. Up to now the Terrain Meshes could be a Triangle Mesh or a Height Map. This duality caused various troubles which could be a pain for users. Therefore the Height Map has been separated from the Terrain Mesh and is now an own object in the world: the Height Terrain. Terrain Meshes are again only Triangle Meshes as they used to be and the Height Terrain takes over all height map related tasks. I'm not going to say more about Height Terrains as their use is similar to what we had before and most developers know those already. One major change to note is that the height terrain is now saved in a separate XML file and is no more interleaved with the World Sectors used by the game. The DragonScript module contains now a Height Terrain Manager which makes it very easy to use height terrains.
This has been the major part of work. Many games thrive for larger and more complex out-door sceneries to immerse the player into the game world. Various problems arise with such endeavors ranging from content creation to rendering and physics simulation. The Drag[en]gine provides now a nifty system to assist mappers in creation of such out-door sceneries focusing on:
Most games can not get far without some kind of Particle System. The Drag[en]gine is receiving a set of those geared for different purpose. So far the first and most simple kind of particle system has been implemented. This is the kind of particle system most people are accustomed to so I will not explain more. A nifty trick to note is that particle systems in the Drag[en]gine use Texture Properties which makes them flexible. Like prop fields particles are influenced by force fields. In the videos below pay attention how the smoke and water drops react similar to the plants waving in the wind.
Some changes are not that big to justify an own section so they end up here. First notable change is that the Animator Editor has now support to attach various objects. This allows to test quickly how actors look like if animated using various equipment. The last change is an experimental Python Scripting Module. This shows how the Drag[en]gine is entirely independent of a scripting language. Developers can choose to use either the strongly typed DragonScript language or the dynamically typed Python language. After all the Drag[en]gine is about adapting to the developer not the other way round. Some changes have been made too on the game itself but most of those do not translate into screenshots. A few though have been added to the Epsylon Profile without a news post.
The screenshots below illustrate the reworked World Editor interface as well as ruleswork of the two vegetation layers used in the demonstration world.
| 
| 
These two videos shows all the new stuff. In both videos prop fields, particle systems and force fields can be watched in action. The first video has the wind strength set to 2.5 bft ( beaufort ) and the second to 6 bft. The water is done with particles for testing purpose only and would usually not be done this way.
Video 1 | Video 2
( Non-Streamed version can be found here and here at slower download speed )
The next work batch concentrates more on in-door rendering including optimizations for rendering as well as improving editing to allow mappers to place content faster.
Quite some time passed since the last news post for a reason. A lot of changes and additions have been made recently to the engine and especially to the editing tools. After all the Drag[en]gine is supposed to be useful for all kinds of people interested in game development hence quite some time has been and will be spent on providing an easy to use yet powerful game engine and editing tools. To achieve this goal a new tool has been put in place: the DE-IGDE. But first things first.
On the game engine front changes have been made to the world/scene system. Up to now for creating a game a developer had to create a world populating it with scenes which represented evenly spaced clusters of space in the world. This has been done to cope with the precision problem that any game with a large world afflicts. This system has though been cumbersome to use for both the game developer as well as the module authors. Hence a change has been made especially looking at the increase of 64-bit systems. The scene objects have been dropped altogether. All kinds of elements are now added to the world object directly. For the position 'double' precision values are now used. Using this new system a possible world size of up to 1mio km is possible with a precision of 1um. For comparison the earth has roughly a circumference of 40'000km and even the largest game worlds so far did not remotely scratch on these numbers. There's enough space left for even the largest game worlds if required without sacrificing precision while keeping things simple.
Another change happened on the animator system. The existing system lacked some flexibility and could become a bit cumbersome to use in complex animation scenarios. To account for this the system has been reworked and new elements added. Now links and targets can be used which provide a more fine grained control over the mixing of rules. Furthermore a new animator rule has been added which stems from movie CG too, the foreign state rule. This rule allows to copy and modify bone states. The Wiki has been updated with informations about the animator system.
On the physics side the touch sensors have been extended with more functionality. They are very useful for various purposes ranging from ground detection to sensing objects entering and leaving areas. Using touch sensors instead of testing for collisions on your own has a couple of advantages. You can either just listen for enter/leave notifications ( useful for passive sensing like for example triggers ) or test the touched content for collision ( useful for actively testing what occupies a given slab of space ). Since you can test this way only a small set of objects it is fast allowing to do more collision queries for improved AI. The Wiki contains now informations about sensors.
Last but not least the game engine switched license to the L-GPL. This has been done to avoid potential license traps and to allow a wider usage of this game engine for free and commercial usage.
As mentioned in the introduction to this news post the editing tools received a major overhaul. To increase productivity with the Drag[en]gine the existing editors have been fusioned together into the IGDE: The Drag[en]gine Integrated Game Development Environment. The IGDE is now the one-stop solution to create games with the Drag[en]gine ( except using Blender or GIMP or other tools for working with specific assets like images or modeling ). Going with the philosophy of the Drag[en]gine the IGDE is also build in a modular fashion. Editors are simply modules loaded into the IGDE and can be extended, added and modified without harming each other. So far the rig editor, animator editor and world editor module are included in the IGDE. Many more will follow since the editor framework is now streamlined and new editors can be quickly created and added. The editor modules can communicate with each other and the IGDE hence it is not just a collection of editors.
Both the editors received improvements alongside the implementation of the IGDE. The rig editor has now better display of bones, shapes and constraints ( more worked on ). The world editor received a new painting mode to paint holes on height map terrains to allow shafts down into the ground as well as cave systems connecting straight to the surface. The animator editor received a playground to conveniently test created animators. In addition a locomotion testing system has been added which simulates to some extend the typical FPS movement manipulating controllers using the mouse and keyboard ( you can assign controllers to different locomotion attributes for testing ). The animation result can be different than in the game depending on how you use animators. All editors have been modified to have now the same look and feel.
A lot of screenshots have been added of the reworked editors including the IGDE. Here only two of the entire 9 images. Find the rest in the gallery.
| 
I also tried to record a video of the locomotion testing system in the animator editor. Since I could not find an application able to capture both the editor window and the OpenGL output inside I had to resort to a CamCorder. I'm having though troubles to upload the video here so no link to it yet. Watch out for the addition of the video ( it will notify you ) once I managed to pull it off.
The upcoming steps now are: improving on the IGDE, adding new editors, fixing some physics issues and adding engine features not implemented yet.