|
Forum > Resources and Tools
[TOOL] [WotLk] ADTForge
<< < (5/6) > >>
Scytheria23:
Bumping because of big edit to the first post
Scytheria23:
:o Ok, some success with alphamap support, but there is a major snag...
The immense quantity of data held by the tool for 12x12 ADTS (4.8 million heights per ADT, 4 million alpha values, AreaIDs, GroundEffects, etc) has resulted in a very slow tool that only works on high-spec machines. Even with a monster PC, it grinds to a crawl. As such, I have been forced to reduce the map size to a more manageable 4x4 ADTS (one ninth of the original area). Of course, it will remain possible to tile multiple sets of 4x4 to make larger maps (although there may be seam problems between maps if heights are not carefully managed), but the working area had to be scaled down.
Edit: OK, got it back up to 8x8, which is much more useful. I did this by reducing the 'undo' steps to just one (the last operation) and by squeezing some data that was stored in multiple integers as flags (a single byte).
Skarn:
--- Quote from: "Scytheria23" ---:o Ok, some success with alphamap support, but there is a major snag...
The immense quantity of data held by the tool for 12x12 ADTS (4.8 million heights per ADT, 4 million alpha values, AreaIDs, GroundEffects, etc) has resulted in a very slow tool that only works on high-spec machines. Even with a monster PC, it grinds to a crawl. As such, I have been forced to reduce the map size to a more manageable 4x4 ADTS (one ninth of the original area). Of course, it will remain possible to tile multiple sets of 4x4 to make larger maps (although there may be seam problems between maps if heights are not carefully managed), but the working area had to be scaled down.
Edit: OK, got it back up to 8x8, which is much more useful. I did this by reducing the 'undo' steps to just one (the last operation) and by squeezing some data that was stored in multiple integers as flags (a single byte).
--- End quote ---
You need to do some task through multithreading. It wil increase the capacity of the tool in a really big way. I assume even larger maps will be posassible to get generated.
Scytheria23:
@ Skarn
As much as possible is already multithreaded, but the problem is that most operations cannot run in parallel, each being totally dependent on the result of the last. The issue is simply one of bytes. One ADT requires 37120 floating point heights, 4194302 bytes of alphamap information, other data besides. For 12x12 ADTs this came to over 625 million bytes being manipulated or stored for each layer of work (I had five per ADT). Few machines can cope with that.
I am working on a code cleanup, which is freeing quite a lot of memory, some compression of data, moving a few routines around, and this is all helping. I don't think I'll get back to 12x12, but 8x8 is working well and quickly.
Skarn:
--- Quote from: "Scytheria23" ---@ Skarn
As much as possible is already multithreaded, but the problem is that most operations cannot run in parallel, each being totally dependent on the result of the last. The issue is simply one of bytes. One ADT requires 37120 floating point heights, 4194302 bytes of alphamap information, other data besides. For 12x12 ADTs this came to over 625 million bytes being manipulated or stored for each layer of work (I had five per ADT). Few machines can cope with that.
I am working on a code cleanup, which is freeing quite a lot of memory, some compression of data, moving a few routines around, and this is all helping. I don't think I'll get back to 12x12, but 8x8 is working well and quickly.
--- End quote ---
Well, if it does not run in parallel what is the problem then? Let's say on a powerful PC it takes 1 minute to generate the map, on a weak one it takes half an hour. If stuff is managed properly and the memory is freed when necessary, the app is not gonna crash because it is weak PC. It will just take longer to get the result.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
|