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.
Another take on shadow casting and physics. This time the point lights.
Posted by Dragonlord on Oct 25th, 2009
In this batch of work the point light source and physics constraints had been of interest. The point lights so far did not have a usable shadow casting which works with half-shadows and is not too slow. Although ATI messes up again a usable solution has been found. It's not perfect but enough for a first release ( can be improved easily later on ). Furthermore physics constraints had been revisited to fight stability issues ( exploding constraint ). Since this is a foreign physics library and a
For point light shadows there exist not many solutions. In fact only Cube Shadow Mapping is a solution as anything else ( dual paraboloid shadow maps or other funny mapping schemes ) suffer from many implementation problems. Besides it can be expected that cube mapping support ( especially depth cube maps ) will be improved more and more with upcoming graphic cards and drivers hence it is okay to target these as a solution. Unfortunately the current state of cube mapping in OpenGL/GLSL is rather lacking. ATI for example lacks proper support for depth cube maps. That is the support is there but rendering to a depth cube map is 10 times slower than rendering to a color cube map. nVidia seems to not suffer from this problem but the test machine with the nVidia card is a laptop and these do not have the required GPU power. So the only solution right now is using a color cube map where the depth is stored as RPG value. This though disallows the use of filtering and requires to do PCF inside the shader. The result are of course rather blocky. As a solution the shader PCF version uses now a noise texture to jitter the sampling. This way the result is less blocky albeit having a bit of noise. To improve speed a secondary code path has been added which uses a little trick in that shadows are rendered to a smaller texture than the screen. This way a bluring obtained for free and only 1/4 ( or even less if the reduction facter is further increases ) of pixels do the PCF filtering. A reduction factor of gives similar results to a full shadow run but improves speed noticeable. Here two images which show on one side the result and on the other comparisson of 3 different reduction levels.
In addition the half-shadow code is now also in use for the point shadows. Hence shadows by walls are black while shadows of objects in the room are half black to simulate in a primitive way light bouncing off the walls. Furthermore point lights now also use light volumes to which reduces the number of pixels processed by the expensive shadow shader. Using all this the point lights with shadows have a reasonable performance. There are though still a couple of optimization tricks left to beaf up the speed.
For the physics BulletPhysics library is used. While a nice library it suffers from some constraint problems which cause the simulation to explode for no obvious reason. As it turned out one of the provided constraints in the library is bugged and tends to explode. A generic solution has been used which is not as fast as the specialized constraint but it does not explode. In general though there are still a couple of stability issues left with the BulletLibrary which is understandable since this project is work in progress too. One of the next points on the list is the inclusion of rope physics. Bullet has according code already and it just needs to be adapted. This should help with certain objects like the ceiling lamp from the last news post.
Putting all together a little video trying to show how the point shadows behave. The fixed constraints are also included. Now the video constains some oddities with the physics simulation. This is because the video capture app hooks itself into the OpenGL graphic system and this causes troubles with the engine. Besides the capturing dropped speed by 50% and more. This test runs otherwise between 50 and 70 fps ( less with higher resolution obviously ). It is therefore adviceable to use point lights modestly. To light rooms semi-point lights are faster and the preferred solution. Yet though you have the possibility to add point lights for where it is required. You can disable shadows on a per-light basis if required. A light importance parameter allows the designer to designate how important the shadow casting of a light source is. The Graphic Module can then use this as a hint to figure out which shadows to draw and which not ( or which to fake if possible ). So here is the video.
Some additional work on the rig editor this time. One important addition is the Mirror Bone feature. This allows the designer to copy collision shapes, constraints and other physics properties from one side of the rig to the other. The appropriate mirroring is done on the fly. Just select the bones you want to mirror to the other side and use the mirror bone menu option. Saves a lot of leg work especially with complex rigs. Furthermore the feature to import bones from other rigs has been added. You select the bones and then what rig to import. For the selected bones the collision shapes, constraints and physics properties are replaced with the matching bones in the rig file. This allows to alter rig files with applications which do not preserve physics informations or to store boiler plate rigs aside which can use as stepping stone for new rigs.
The special video is still a topic. With the last additions it should be doable now. Besides this demo reel the ropes physics is planed to be tackled. The main focus though is now on doing this demo reel which serves not only as a demonstration video but also to provide a sort of test case for the engine features. So stay tuned.