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.
Rather that just using the dmap command alone (as shown below):
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
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]