IdTech4 Open Source - Revision history

Nbohr1more: /* Done */

2024-12-21T07:54:09Z

Done

← Older revision		Revision as of 07:54, 21 December 2024
Line 107:		Line 107:
	\|Graphic		\|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.		\|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. ~~Code is committed, Normal Maps were not converted due to concerns about Intel compatibility. Serpentine was last looking into RGTC as an alternative~~.		\|Performance increase. Graphic enhancement. Bigger maps for less RAM. As of TDM 2.10 we support BC5 DDS normal map compression

	\|-		\|-

Nbohr1more: /* ToDo */

2024-04-30T16:24:52Z

ToDo

@@ Line 20: / Line 20: @@
 |The GUI is 4:3 (640x480), but covers always the entire screen and is thus [https://bugs.thedarkmod.com/view.php?id=5282 distorted on 16:9].
 |GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/
 |-
@@ Line 36: / Line 46: @@
 |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? The unused megatexture code is very similar to lightmap code. We could use the megatexture mod's reverse engineered vfp as a starting point and add PCX support. We'd want to correct the faulty UV space issues since this was built for terrains initially and stretches UV's vertically (etc).
 |Performance increase. Graphic enhancement. Migrated content?
 |-

Nbohr1more: /* ToDo */

2024-04-30T15:56:41Z

ToDo

← Older revision		Revision as of 15:56, 30 April 2024
Line 16:		Line 16:
	!bgcolor=#d0d0e0\|Possible outcome		!bgcolor=#d0d0e0\|Possible outcome

			\|-
			\|GUI
			\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [https://bugs.thedarkmod.com/view.php?id=5282 distorted on 16:9].
			\|GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/

	\|-		\|-
Line 43:		Line 46:
	\|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.		\|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.
	\|IceColdDuke has offered assistance porting his skinning code https://bugs.thedarkmod.com/view.php?id=3984		\|IceColdDuke has offered assistance porting his skinning code https://bugs.thedarkmod.com/view.php?id=3984

	\|-
	~~\|GUI~~
	~~\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [https://bugs.thedarkmod.com/view.php?id=5282 distorted on 16:9].~~
	~~\|GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/~~

	\|-		\|-

Nbohr1more: /* ToDo */

2024-04-30T14:16:10Z

ToDo

← Older revision		Revision as of 14:16, 30 April 2024
Line 28:		Line 28:
	\|Performance increase, Fur shaders, Higher poly-counts. Note: Some of this functionality was probably already exposed but no ARB programmers could use it because it		\|Performance increase, Fur shaders, Higher poly-counts. Note: Some of this functionality was probably already exposed but no ARB programmers could use it because it
	would have increased the length of the entire interaction shader for anything "lit" though I don't believe anyone's tried calling a VFP from a material that includes the whole light interaction chain (which might've also worked. Nonetheless this remains open for improvement with robust native implementations.		would have increased the length of the entire interaction shader for anything "lit" though I don't believe anyone's tried calling a VFP from a material that includes the whole light interaction chain (which might've also worked. Nonetheless this remains open for improvement with robust native implementations.

	\|-
	~~\|Mapping~~
	\|<s>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.</s>
	\|<s>Performance. Ease of use for mappers.</s> suspended. changing the map format has been deemed too risky. could possibly be addressed via a Dark Radiant plugin that automates model export when vertex colors are applied. Currently scripts exist to approximate this functionality.

	\|-		\|-
Line 69:		Line 64:
	\|Add the ability to have multiple dynamic LightFalloffImage stages		\|Add the ability to have multiple dynamic LightFalloffImage stages
	\|Use ''Texture Sheets'' to render multiple light passes and maximize the work allocated to each light render. (Less waste.) Animated light texture effects can have all 3 axis of movement.		\|Use ''Texture Sheets'' to render multiple light passes and maximize the work allocated to each light render. (Less waste.) Animated light texture effects can have all 3 axis of movement.

			\|-
			\|Mapping
			\|<s>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.</s>
			\|<s>Performance. Ease of use for mappers.</s> suspended. changing the map format has been deemed too risky. could possibly be addressed via a Dark Radiant plugin that automates model export when vertex colors are applied. Currently scripts exist to approximate this functionality.

	\|}		\|}

Nbohr1more: /* Done */

2024-04-30T14:15:21Z

Done

← Older revision		Revision as of 14:15, 30 April 2024
Line 130:		Line 130:
	\|<s>Eliminate as many hard-coded limits as possible.</s>		\|<s>Eliminate as many hard-coded limits as possible.</s>
	\|<s>Reduce mapper frustration.</s> A number of limits have been removed. Some of these changes have unforeseen consequences so removing all limited is probably not feasible		\|<s>Reduce mapper frustration.</s> A number of limits have been removed. Some of these changes have unforeseen consequences so removing all limited is probably not feasible

			\|-
			\|GUI
			\|Font rendering is buggy (only alpha map, [https://bugs.thedarkmod.com/view.php?id=2812 misses character 0xFF], no Unicode etc.).
			\|Better looking GUI and easier translations.

	\|}		\|}

Nbohr1more: /* ToDo */

2024-04-30T14:14:57Z

ToDo

← Older revision		Revision as of 14:14, 30 April 2024
Line 42:		Line 42:
	\|Graphic		\|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.		\|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).		\|More accurate reflective materials. Gold loot (etc). Tracker: https://bugs.thedarkmod.com/view.php?id=5239

	\|-		\|-
Line 48:		Line 48:
	\|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.		\|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.
	\|IceColdDuke has offered assistance porting his skinning code https://bugs.thedarkmod.com/view.php?id=3984		\|IceColdDuke has offered assistance porting his skinning code https://bugs.thedarkmod.com/view.php?id=3984

	\|-
	~~\|GUI~~
	~~\|Font rendering is buggy (only alpha map, [http://bugs.angua.at/view.php?id=2812 misses character 0xFF], no Unicode etc.).~~
	~~\|Better looking GUI and easier translations.~~

	\|-		\|-

Nbohr1more: /* ToDo */

2024-04-30T14:11:03Z

ToDo

← Older revision		Revision as of 14:11, 30 April 2024
Line 47:		Line 47:
	\|Animation		\|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.		\|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.
	\|~~Thus far, this~~ has ~~proven to be the single largest performance jump from Vanilla Doom 3 to Doom 3 BFG. There is an open bounty to get this ported:~~		\|IceColdDuke has offered assistance porting his skinning code https://bugs.thedarkmod.com/view.php?id=3984
	https://~~www~~.~~bountysource~~.com/~~issues/2883499-port-gpu-skinning~~

	\|-		\|-

Nbohr1more at 14:08, 30 April 2024

2024-04-30T14:08:28Z

← Older revision		Revision as of 14:08, 30 April 2024
Line 57:		Line 57:
	\|-		\|-
	\|GUI		\|GUI
	\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [~~http~~://bugs.~~angua~~.at/view.php?id=~~2703~~ distorted on 16:9].		\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [https://bugs.thedarkmod.com/view.php?id=5282 distorted on 16:9].
	\|GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/		\|GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/

Nbohr1more: /* ToDo */

2024-04-30T13:54:24Z

ToDo

← Older revision		Revision as of 13:54, 30 April 2024
Line 58:		Line 58:
	\|GUI		\|GUI
	\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [http://bugs.angua.at/view.php?id=2703 distorted on 16:9].		\|The GUI is 4:3 (640x480), but covers always the entire screen and is thus [http://bugs.angua.at/view.php?id=2703 distorted on 16:9].
	\|GUI looks better on 16:9 and on multi-monitor setups.		\|GUI looks better on 16:9 and on multi-monitor setups. Potential fix: https://forums.thedarkmod.com/index.php?/topic/22325-i-made-a-fix-for-ui-display-for-non-169-resolution/

	\|-		\|-

Nbohr1more: /* Done */

2018-06-04T02:55:29Z

Done

← Older revision		Revision as of 02:55, 4 June 2018
Line 131:		Line 131:
	\|Shadow Volumes (silhouettes) 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.		\|Shadow Volumes (silhouettes) 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.
	\|TDM 2.06 has buggy initial support for Shadow Maps and 2.07 (SVN) has further improvements.		\|TDM 2.06 has buggy initial support for Shadow Maps and 2.07 (SVN) has further improvements.

			\|-
			\|Mapping
			\|<s>Eliminate as many hard-coded limits as possible.</s>
			\|<s>Reduce mapper frustration.</s> A number of limits have been removed. Some of these changes have unforeseen consequences so removing all limited is probably not feasible

	\|}		\|}