The Drag[en]gine is a fully customizable game engine and game development environment designed with modularity and extensibility in mind not requiring expensive licenses.
Tackled two nasty problems which nagged us for quite some time about robust shadow casting and getting dragons to walk.
Posted by Dragonlord on Oct 10th, 2009
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 shadows which is 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 tessellation step ). This should solve the shadow problem now once and for all. 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.
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:
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.
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.
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.