IdTech4 Open Source
From The DarkMod Wiki
id Software has a long history making the code to their engines open source after a while. Even after being sold to Zenimax, this trend continued. The source code can be found on the officiel FTP server from id software.
So there is hope that idTech4 (the engine behind Doom 3 and Quake 4) will also be open sourced. For The Dark Mod this means that we can fix a long list of issues that are currently not possible.
Here is a small, incomplete list, in no particular order:
Todo: add more examples
| Category | Issue | Possible outcome | |
|---|---|---|---|
| Sound | EAX does not work under Linux. | Works there, too. | |
| Graphic | The lightgem needs to render to a texture and transfer this texture back to the CPU via a complicated in-memory file scheme. | Performance increase. | |
| Graphic | No instancing. Multiple instances of the same model are all rendered one by one, instead of uploading it once and then telling the graphic card to render them all in one go. | Performance increase. | |
| Graphic | No access to the Z-Buffer. Without access to this data, any depth-based fragment shader effects like SSAO or Depth of Field require an extremely expensive z-pass render. | Performance increase. More effect options. | |
| Coding | Single-threaded coding. It may be possible to divide the sub-systems into separate execution threads for processing on separate cores once the source code is available. The game Prey has implemented this type of change to Id Tech 4. On the extreme side of this concept, OpenCL could be used to perform AI path-finding, or physics calculations. | Performance increase. | |
| Graphic | Shadow Volumes are calculated on the CPU. Moving to a GPU calculated Shadow Volume or a Shadow Mapping technique like Parallel Split Variance Shadow Maps would allow more on-screen geometry with active lighting applied. Soft shadows would also be MUCH less expensive than the current Z-Buffer render and Post-Process method. | Performance increase. Higher poly-counts. More active lights. Soft shadows. | |
| Graphic | No access to Vertex positions. For vertex shader or geometry shader (DX10+ hardware) operations like R2VB, Vertex Texturing or Tessellation the correct Vertex locations will be needed. Fur shaders would also be possible... | Performance increase, Fur shaders, Higher poly-counts. | |
| Mapping | Brushes cannot have Vertex Colors or Vertex Normals. Adding these attributes would give Brushes near feature parity with Models and allow for more seamless mixtures of the two construction methods. Brushes could have Patch style smoothing and curves yet could be properly scissored by a Visportal. Translucency could be applied to Brush-work prefabs. | Performance. Ease of use for mappers. | |
| Graphic | Support for Light-Maps or Deluxe-Maps. While static lighting methods are not really an ideal usage for this engine, these features can have their utility. You could bake ambient bounced lights for areas that are predominantly statically lit. To make these methods more Doom 3 compatible, these could be implemented as an Ambient Light (3D texture support?) as a more robust extension of the Strombine method that is currently available (but very cumbersome). Maps made in other engines (without game specific assets) could be more easily migrated? | Performance increase. Graphic enhancement. Migrated content? | |
| Graphic | LATC2 Normal Map compression support (AKA OpenGL 3Dc) See: http://www.opengl.org/registry/specs/EXT/texture_compression_latc.txt ... Reduced Normal Map memory requirements both on the storage volume and in graphic RAM. | Performance increase. Graphic enhancement. Bigger maps for less RAM. | |
| Graphic | Local Cubemaps. (See HL2 env_cubemap.) Granting the ability to have reflective materials more accurately reflect their environment. It may be possible to setup scripted material fades (shaderparm?) to implement this with the current SDK framework but it would be yet another CPU dependent operation. The Skin changing in the LOD system could also be used perhaps? This one is definitely questionable about requiring Open Source, but is may be beneficial to set this up in the renderer. | More accurate reflective materials. Gold loot (etc). | |
| Animation | GPU Skinning. Having the GPU stretch and transform the mesh would be tremendous performance enhancement for animations and would allow for extremely detailed facial animations like Team Fortress 2. | Better animations. Performance Increase. | |
| GUI | Font rendering is buggy (only alpha map, misses character 0xFF; no Unicode). | Better looking GUI and easier translations. | |
| GUI | The GUI is 4:3 (640x480), but covers always the entire screen and is thus distored on 16:9. | GUI looks better on 16:9 and on multi-monitor setups. | |
| Sound | Determine why "no_dups" doesn't always work and correct it. Remove the SDK workaround for this problem. | Better sound randomization. | |
| Entities | Correct the occasional bad "trace" the engine performs. | Eliminate spatial relationship problems. | |
| Mapping | Eliminate as many hard-coded limits as possible. | Reduce mapper frustration. | |
| Coding | Grant the ability to create NEW material keywords | This would allow per-material effects that do not require every surface to include the keyword stage. Example: Fur Shaders, Anisotropic Material, etc. | |
| Graphic | Add the ability to have multiple dynamic LightFalloffImage stages | Take advantage of Texture Sheets to render multiple light passes from one texture and maximize the work allocated to each light render. (Less waste.) Animated light texture effects can have all 3 axis of movement. | |
| Graphic | Add keywords for Cubemap light method and 3D texture light methods | Extend the Doom 3 light method to more projection types without the need to replace or upgrade existing maps and assets. |
