[TOOL] [WotLk] ADTForge

[Songen]

Well, I checked and it is a greyscale bmp file that is 1537x1537 but it is not 2,368,126 bytes, its smaller than that.

[Songen]

Seems like saving with GIMP actually fixed it o.O

[Scytheria23]

@ Songen

Good to hear.  Do give feedback on your results (pics would be nice).  If you think something could be improved or think of a missing feature, there's still time for me to fix/add into the more substantial sequel.

[matija168]

Is there any way this tool may get alphamap support any time in the future. As in, to create a base alphamap which would be copied over all ADTs.

[Scytheria23]

Is there any way this tool may get alphamap support any time in the future. As in, to create a base alphamap which would be copied over all ADTs.

The answer is kind-of.  The base-layer textures, yes.  You're about two weeks away from seeing a MAJOR overhaul of this tool.  The new version, now renamed ADTForge, has a proper Windows interface, many more tools, and is flexible (e.g. you can add as many layers of height info in whatever ways you want).  You can set the primary layer textures, set AreaIDs, impassible flags, animate the textures, do cube-maps, add ground effects and so on.  You can also rip height info from existing ADTs, manipulate it, and merge it into your own height data.  I'm now in the final testing phase and writing the manual/tutorials.  Watch this space!

Scy

[Scytheria23]

Bumping because of big edit to the first post

[Scytheria23]

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]

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).

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]

@ 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.

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.

[Insanity]

@ Scytheria

How is the development going?  I'm really looking forwarded to the updated version. Would you be willing to re-post a link the previous version in the meantime (I thought I had a copy but I can't seem to find it)?  Thanks

[Scytheria23]

@Insanity

The project is still in development, somewhat slowed by my real life workload.  At present, a volunteer is beta-testing some of the main features, but the whole thing is a way off completion. 

I'm afraid I don't have any copies of the original tool, but trust me, it was crapola.

Scy

[Insanity]

No need to explain, life likes to pile it on (especially if there is a pile there to begin with.)  Thanks for the reply.  Let us know if the unskilled masses can help.

[Kaev]

Any news? Was actually looking forward to finally play around with this.