Dmap: Difference between revisions
Nbohr1more (talk | contribs) |
2GB limit during dmapping: use 64-bit build |
||
| (11 intermediate revisions by one other user not shown) | |||
| Line 2: | Line 2: | ||
This article can include anything about dmap. I just started it as a placeholder to list when and when not to.... | This article can include anything about dmap. I just started it as a placeholder to list when and when not to.... | ||
Also... do not Dmap while a mission is installed. Uninstall the mission then dmap. | |||
== When do I need to dmap? == | == When do I need to dmap? == | ||
| Line 17: | Line 19: | ||
* After moving a brush or patch entity | * After moving a brush or patch entity | ||
* After changing a spawnarg (entity keyvalue), unless it affects the origin or rotation of a model. | * After changing a spawnarg (entity keyvalue), unless it affects the origin or rotation of a model. | ||
== Delete Proc, CM, AAS == | |||
When you dmap, in many cases the existing Proc, CM, and AAS files will not be overwritten. | |||
It is advisable to delete all the files except the map, script, and custom assets. | |||
== Optimization Options == | == Optimization Options == | ||
| Line 28: | Line 36: | ||
</pre> | </pre> | ||
You can improve the way the map compiler optimizes the map | You can improve the way the map compiler optimizes the map through the use of "switches". | ||
The most commonly used is "shadowopt 2" | The most commonly used switch is "shadowopt 2" | ||
(CAUTION: There is one report that this caused pathfinding problems.) | (CAUTION: There is one report that this caused pathfinding problems.) | ||
| Line 40: | Line 48: | ||
</pre> | </pre> | ||
Another | Another more common switch is "lightCarve". | ||
This will split the geometry based on light boundaries. | This will split the geometry based on light boundaries. | ||
| Line 56: | Line 64: | ||
</pre> | </pre> | ||
Even further, advanced mappers can use: | * By most accounts manually splitting light counts is more beneficial than LightCarve so using this switch can be seen as a "lazy technique". | ||
* (Though it's arguably still cumbersome because proper LightCarve application usually requires some pre-planning...). | |||
---- | |||
===Even further, advanced mappers can use:=== | |||
* The "noFragment" keyword in materials to '''prevent''' some surfaces from splitting during compile | * The "noFragment" keyword in materials to '''prevent''' some surfaces from splitting during compile | ||
* The "discrete" keyword in materials to ensure that specified surfaces are '''always split''' during compile | * The "discrete" keyword in materials to ensure that specified surfaces are '''always split''' during compile | ||
These techniques are also referred to as [[ | These techniques are also referred to as [[Performance:_Essential_Must-Knows#Brush_Carving|"Brush Carving"]] | ||
* More details at: | * More details at: https://modwiki.xnet.fi/Dmap_%28console_command%29 | ||
== Troubleshooting == | == Troubleshooting == | ||
| Line 69: | Line 84: | ||
=== Malloc Errors === | === Malloc Errors === | ||
If you get malloc (memory allocation) errors while dmapping then this might be due to the limitation of the program even if you have plenty of RAM. If you have | If you get malloc (memory allocation) errors while dmapping then this might be due to the limitation of the program even if you have plenty of RAM. | ||
If you have more than 4GB of RAM and 64-bit OS, then you should dmap in 64-bit build of DarkMod (starting from 2.06). Keep in mind that memory consumption in 64-bit build is usually higher than in 32-bit build. | |||
[[http://www.ntcore.com/4gb_patch.php NTCore]] | If you have 3GB RAM or more then you can get 32-bit build of DarkMod to access up to 4GB by using a 3rd party patch called NTCore. This is a simple Windows application. You just browse to TheDarkMod.exe and click it and it fixes it and makes a backup just in case. That's it! Here is the link: [[http://www.ntcore.com/4gb_patch.php NTCore]] | ||
[[Category:Editing]] | [[Category:Editing]] | ||
Latest revision as of 07:48, 24 March 2018
started by Fidcal
This article can include anything about dmap. I just started it as a placeholder to list when and when not to....
Also... do not Dmap while a mission is installed. Uninstall the mission then dmap.
When do I need to dmap?
- After creating new brush or patch worldspawn.
- After moving/rotating new brush or patch worldspawn.
- After renaming a brush or patch entity, eg, func_static.
- After rotating a brush or patch entity, eg, func_static.
- After adding AI may need pathfinding recalculating (included in dmap by default.)
- After adding or moving a light (shadows are precalculated for static, shadowcasting lights).
When do I NOT need to dmap?
- After adding a path_corner or other path entities.
- After moving a brush or patch entity
- After changing a spawnarg (entity keyvalue), unless it affects the origin or rotation of a model.
Delete Proc, CM, AAS
When you dmap, in many cases the existing Proc, CM, and AAS files will not be overwritten. It is advisable to delete all the files except the map, script, and custom assets.
Optimization Options
Rather that just using the dmap command alone (as shown below):
dmap map_name.map
You can improve the way the map compiler optimizes the map through the use of "switches".
The most commonly used switch is "shadowopt 2"
(CAUTION: There is one report that this caused pathfinding problems.)
dmap shadowopt 2 map_name.map
Another more common switch is "lightCarve".
This will split the geometry based on light boundaries. It can improve performance at the expense of a larger map file.
Mappers who are proficient with this compile method know to arrange and size their lights such that they are broken via easy symmetry or ratios.
This is primarily beneficial to maps with simple but wide-open areas with large light volumes (example: a large warehouse).
dmap lightCarve map_name.map
- By most accounts manually splitting light counts is more beneficial than LightCarve so using this switch can be seen as a "lazy technique".
- (Though it's arguably still cumbersome because proper LightCarve application usually requires some pre-planning...).
Even further, advanced mappers can use:
- The "noFragment" keyword in materials to prevent some surfaces from splitting during compile
- The "discrete" keyword in materials to ensure that specified surfaces are always split during compile
These techniques are also referred to as "Brush Carving"
- More details at: https://modwiki.xnet.fi/Dmap_%28console_command%29
Troubleshooting
Malloc Errors
If you get malloc (memory allocation) errors while dmapping then this might be due to the limitation of the program even if you have plenty of RAM.
If you have more than 4GB of RAM and 64-bit OS, then you should dmap in 64-bit build of DarkMod (starting from 2.06). Keep in mind that memory consumption in 64-bit build is usually higher than in 32-bit build.
If you have 3GB RAM or more then you can get 32-bit build of DarkMod to access up to 4GB by using a 3rd party patch called NTCore. This is a simple Windows application. You just browse to TheDarkMod.exe and click it and it fixes it and makes a backup just in case. That's it! Here is the link: [NTCore]
