Dmap: Difference between revisions
Nbohr1more (talk | contribs) |
Nbohr1more (talk | contribs) |
||
Line 56: | Line 56: | ||
</pre> | </pre> | ||
By most accounts manually splitting light counts is more beneficial than LightCarve so using this switch can be seen as a "lazy technique" ( | * 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: | Even further, advanced mappers can use: |
Revision as of 00:28, 26 April 2011
started by Fidcal
This article can include anything about dmap. I just started it as a placeholder to list when and when not to....
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.
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: http://www.modwiki.net/wiki/Dmap_(console_command)
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 3GB RAM or more then you can get Dark Mod (doom3) to access up to 4GB by using a 3rd party patch called NTCore. This is a simple Windows application. You just browse to Doom3.exe and click it and it fixes it and makes a backup just in case. That's it! Here is the link.....
[NTCore]