v2.4.2.6 attribute maps

[cliff]

Howdy, Aaron.

Hadn't upgraded to 2.4.2.6 yet, but some of my users noticed that the attribute PNG maps no longer support colour mapped. Is there some better way to determine attribute types? In its current form, my tool is dependent on that.

[Aaron]

Hi Cliff,

I'm sorry, I accidentally dropped the colour-mapping from the PNG options list, but I assure you the code is still intact and will return in the next update.

> Is there some better way to determine attribute types?

I think the safer way is to use the PNG in 16-bit greyscale mode, or else use the attributes map file format (which has the same data, but isn't compressed as with PNG). In these files, each pixel contains a byte for climate ID and a byte for land type ID. When read together as one unsigned short integer, these values give a unique identifier for each land type in the attributes map. You can get the list of IDs with their matching land type/climate/texture names using the 'operations->attributes map->export type info list', which produces a file that looks like this:

Code: Select all

L3DT texture list

ID#   Land type   Climate   nTextures   TexNameList
2816   "Dry grass"   "Temperate"   4   "..\common\grass\grass1-dry.jpg"   "..\common\grass\grass1-dry.jpg"   "..\common\grass\grass1-dry.jpg"   "..\common\detail\detailmap.jpg"
3584   "Steep dry grass"   "Temperate"   4   "..\common\grass\grass1-dry.jpg"   "..\common\grass\grass1-dry.jpg"   "..\common\grass\grass1-dry.jpg"   "..\common\detail\detailmap.jpg"
4096   "Cliff face"   "Temperate"   2   "..\common\rock\rock1b.jpg"   "..\common\rock\rock2b.jpg"
3840   "Steep dry grass (2)"   "Temperate"   4   "..\common\grass\grass1.jpg"   "..\common\grass\grass1.jpg"   "..\common\grass\grass1.jpg"   "..\common\detail\detailmap.jpg"
1792   "Steep grass"   "Temperate"   4   "..\common\grass\grass1.jpg"   "..\common\grass\grass1.jpg"   "..\common\grass\grass1.jpg"   "..\common\detail\detailmap.jpg"
4352   "Steep cliffs"   "Temperate"   2   "..\common\rock\rock1.jpg"   "..\common\rock\rock2.jpg"



Normally each land type would occupy one line, starting with the ID, then the land type name, the climate name, the number of textures, and then the texture list itself. In the above example the file is wrapping around because each line is quite long, but normally it's just one line per land type.

Anyway, if you read the 16-bit pixel values form the map file, and read this text file, you can map from the AM pixel codes to the actual land type names, textures, etc.

However, if you've got a nice XML parser at hand (and I imagine C# does), you can avoid having to export and read this file by reading from the project and climate files themselves. Each AM pixel consists of a land type byte, followed by a climate byte. Normally, the climate byte will be zero, which corresponds to the first climate in the climate list in the proj file. A climate byte of 1 will be the second climate in the list, and so on. In the project file climate list, you will also find the full paths to the climate definition files. In those climate files you will see a list of land types, and the land type byte in the attributes map pixel identifies the land type in this list. Here, the counting starts at 1 (rather than 0), as 0 is used to indicate an invalid land type/climate. Thus, a land type byte of 1 maps to the first land type in the climate definition. 'Tis a bit more complicated, but that's the way L3DT does it, and thus that's the way I'm least likely to inadvertently mess-up.

Cheers,
Aaron.

[cliff]

Awesome, thanks for the extra data. I'll plan on implementing that in a future version, but for now I'll let my users know that the option will be re-appearing soon.

So, is there a visible flag in the XML project file somewhere that specifies if the AM PNG is colour-mapped or not? It would probably be nice to make my loader flexible enough to handle both, automatically if at all possible.

[cliff]

I remember the question I had run into when looking at the climate files that wasn't clear - when the ID is re-used in 2 climate files that are both used on the map, it wasn't terribly clear how your data was resolving the conflict. What's the logic to this conflict resolution?

[Aaron]

Hi Cliff,

So, is there a visible flag in the XML project file somewhere that specifies if the AM PNG is colour-mapped or not?

If the PNG is a 24-bit image, it's colour-mapped. If it's 16-bit, it's not. That's how I do the switching.

I remember the question I had run into when looking at the climate files that wasn't clear - when the ID is re-used in 2 climate files that are both used on the map, it wasn't terribly clear how your data was resolving the conflict. What's the logic to this conflict resolution?

The values in the attributes map specify not just the land type ID, but also the climate ID. To get the climate and land type IDs from a pixel values, I use the following formulae:

ClimateID = AMpxl%256; (integer modulus)

and

LandTypeID = AMpxl/256; (integer divide)

(where AMpxl is the 16-bit pixel value from the image.)

The climate ID tells you which climate to look in, and the land type ID identifies the land type in that climate. Consequently, providing there 256 or less climates, and 255 or less land types in any climate (0 is reserved), these 2-byte codes uniquely identify each possible land type. I can't remember whether I have a check in the climate manager/editor to enforce these limits (I think so), but I figured no-one would use 257 climates in one map, or 256 land types in one climate. If they do, I may add a 'wide' attributes map option in the future, with 32 bytes per pixel (again using a PNG image, this time in RGBA mode).

Colour-mapped mode, on the other hand, is quite likely to suffer from conflicts, as there's nothing stopping a user from setting the same display colour for multiple land types (in the same or different climates.) Thus, the 16-bit values are guaranteed to be unique within a certain range, whereas the colour-mapped values may or may not be unique, depending on the users' settings. Furthermore, with colour-mapped files there is a chance that the user may edit the image and inadvertantly insert a colour that does not correspond to the display colour of a land type, in which case one cannot lookup the appropriate land type. You could, perhaps, do a nearest-match algorithm (and in fact I might do that, now that I think of it), but that's not guaranteed to get the value the user intended. These are the reasons colour-mapping is not on by default.

Anyway, does this stuff make any sense now?

Cheers,
Aaron.

[cliff]

Yeah, makes great sense. Thanks again for all your support!

[Aaron]

Hi Cliff,

Version 2.4.2.7 is up, and the colour-mapped mode for attributes map PNGs should be back and working.

Cheers,
Aaron.

[DeathTwister]

Hahaha,

dang I been so busy I missed 2-3 updates, DOH, KK maybe good I did /smiles, KK NOTE TO SELF: download new version and find time to play with it all this weekend.

We are very close to opening the world texture repository I hope next week for L3DT beta tests by the end of next week or so thanks to Javabones. I am working on the interface right now, and doing stuff with forums and so on, so we almost to the opening door point I think. Maybe sooner, but just for us L3DTers, The big opening after we know it is all good /smiles. KK back to work. I will post that on the other post when we do go live for L3DT first. Shhh it's a secret ROTFL............

DT