Duplicate Border as an export map option checkbox

[Hypnotron]

Seems clumsy too have to click the Operations\Active Map\Duplicate Tile Borders. Wouldnt this be better to have as an option in the mosaic export dialog when the user is presented with other options such as "Invert Y?"

The current functionality makes it very difficult to figure out if Duplicate Tile Borders is active or not. There is no "checkmark" next to the Duplicate Tile Borders menu item to know if its currently active or not... and what happens if you press it twice? Does it toggle off without any positive feedback (doesn't appear so, appears to do its thing every time you press it... so what does that mean? Pressing it twice results in doubled duplicate borders?)

Very confusing.

[Hypnotron]

Honest, im not even sure this is working properly for heightfields at least.

I get a whole bunch of these:

CMapWrap::GetMinMaxAlt error:
- call to CalcMinMax failed

CMosaicMap::SaveSubMap_FI error
- scale not unified for HF

CMosaicMap::SaveSubMap error
- call to format-specific SaveSubMap failed

I duplicate the borders and then i try to export to bmp and the above errors occur.

[Aaron]

Hi Mike,

Thanks for the feedback. I haven't done any refinement on the 'duplicate tile borders' interface, mostly because I've had no feedback on the subject (until now). I personally don't use it, because L3DTVi2 fixes the tile-seam problem at run-time.

Anyway, I take your suggestions on board, and I'll implement what I can.

Seems clumsy too have to click the Operations\Active Map\Duplicate Tile Borders. Wouldnt this be better to have as an option in the mosaic export dialog when the user is presented with other options such as "Invert Y?"

I'll have a look-into the easiest and most sensible way to insert this option into the export wizard. I can possibly inject 'duplicate borders' into the format options (alongside 'InvertY' &c), but it is a bit hack-ish. Duplicated edges is not a 'state' as such - it is a map-wide operation (currently irreversible) that re-packs every pixel once the map is complete. Nonetheless, I'll see what I can do.

The current functionality makes it very difficult to figure out if Duplicate Tile Borders is active or not. There is no "checkmark" next to the Duplicate Tile Borders menu item to know if its currently active or not

I'll add a check-mark to say whether the operation has been done or not, but there's currently no way to undo this calculation. Would you want to do this? If required I can write the inverter to un-duplicate borders, but I originally didn't think it would be required.

Aside:
Oops, I used the dreaded 'undo' word. There is no chance of L3DT having 'undo' any time soon.

... and what happens if you press it twice? Does it toggle off without any positive feedback (doesn't appear so, appears to do its thing every time you press it... so what does that mean? Pressing it twice results in doubled duplicate borders?)

Yes indeedy, it runs the operation again, so you end up with a two-pixel-wide border of duplicated values. I'll add a check to prevent users doing this twice.

Honest, im not even sure this is working properly for heightfields at least...I duplicate the borders and then i try to export to bmp and the above errors occur.

Oops, I guess I hadn't tried this combination of operations with the heightfield. I'll fix this for the next release, but the work-around is to duplicate the tile borders, then select the 'Utilities->Unify mosaic scales' option, then export as a bitmap. I was just about to delete the 'Unify mosaic scales' option from the menu, but I'm glad I didn't.

Cheers,
Aaron.

[Aaron]

Hello again,

Just to follow-up on the above, in the next release a check-mark is displayed next to the 'Duplicate tile borders' option once it has been done, and the option will be greyed-out to prevent it from being called twice for the same map. I've also fixed that problem you found when duplicating tile borders of the heightfield and then exporting it.

I had a quick play with the inverse-function to undo the border-duplication, but because you lose some information when you duplicate the borders (there's an interpolation), and you lose some more going back (another interpolation), the net result had some artefacts. Rather than give users yet another easy way to corrupt their data, I think I'll leave this one out.

There's no news yet on calling duplicate-borders from the export wizard. I'll let you know when I've had a go at it.

Cheers,
Aaron.

[Hypnotron]

Thanks for the quick response. Look forward to the up coming release, but the info and work arounds will suffice for now.
-Mike

[aeyr]

Hi, I can't seem to figure out exactly what this option does and I'm pretty sure I need it badly.

For instance, I've split a 1024x1024 into a 2x2 mosaic (each 512x512 obviously). I want a 513x513 png export for each HF tile. I cannot for the life of me figure out how to go about this.

I've tried duplicating borders, and that seems to perform some calc, but not actually change the size of the maps. Exporting as a mosaic with 513 as the tile size doesn't work (undefined pixels on the edge). Gah! Please help!

Also, you mention it's non-undoable, but I'm slightly confused. Surely this makes sense as an export flag when exporting the HF tiles to simply dup the corresponding rows/cols only when writing the exported tile files. That way it's non-destructible (as it should be).

[Aaron]

Hi Aeyr,

What this function does at the moment is preserve both tile size and overall map size, but re-organises the contents of each tile so that they contains the matching edge-members of the next tile (it uses a linear-interpolation.) The lerp is lossy, because it's packing the data of 513x512 pixels into 512x512 pixels (for example), and this is why it's irreversible.

Growing the tile size by 1 would remove the need for the lerp, and it's on the to-do list somewhere. As I may or may not have said here or elsewhere, having a state flag in a mosaic map to say 'add a 1 pixel border' would be very bad for the tile cache, particularly in multithreaded calculations, as suddenly the act of loading/saving each tile would require three neighbouring tiles to be fetched. That's why I prefer to handle this as a standalone operation.

That said, it will be possible shortly (once I've released the next API build) to write a plugin whereby you can export the mosaic as another mosaic, in which each tile has been grown by 1. So, a 1024x1024 map comprising 2x2 tiles of 512x512 pixels would become a 1026x1026 map with 513x513 pixel tiles. This is basically trivial, as it involves getting a pixel from one mosaic, and putting it in the other, but using different tile and map sizes. This process would also be reversible (again, needing an import function in a plugin, which is also trivial.) Hmmm...I guess I'll write this plugin myself, as it would be a good test-case for the new functions.

Cheers,
Aaron.

[Aaron]

Hi Aeyr,

Here's the plugin:

http://www.bundysoft.com/L3DT/downloads/zeolite/atGrowTilesByOne.zip

This requires the very latest build of L3DT Pro (v2.4.2.12, 6th of Nov). Consult your reg email for the download link.

The use should be pretty straightforward (the menu option is 'Extensons->atGrowTilesByOne->Grow tile sizes by one'). The only real gotcha is that it only works with the heightfield at the moment. In the next few days I should be able to add the ability to take the 'active' map in the main window display. I'll release the source code once I've finished this round of API expansion.

Cheers,
Aaron.

[aeyr]

Heh, you are quick!

I've tried out this plugin and it looks like it's writing the correct sized files, but unfortunately they are all black.


Incidentally. While I suppose it's nice to be able to do this on all the various types of map, it's really only crucial for the heightmap. Generally, the HM is the only one that's 2^n+1, everything else (lightmap, base texturing, etc) is still 2^n.

[Aaron]

Hi Aeyr,

There may have been a problem with vertical scaling. Care to try again with the latest dev build? (v2.4.2.14, which incudes the plugin)

Cheers,
Aaron.

[aeyr]

The images look good now, the definition is there.

However, I still need the option of writing pages out in reverse y-order (origin on top left, rather than bottom left).

Also, the ability to specify format options (such as PNG compression level) would be very nice. At the very least, defaulting to normal png compression when exporting (as opposed to none) would be good.

If you post up the source, I'd be happy to make a patch for it.

[Aaron]

Hi Aeyr,

However, I still need the option of writing pages out in reverse y-order (origin on top left, rather than bottom left).

Open the file preferences dialog, go to 'project maps->heightfield->png', click 'options', and enable the 'InvertY' option.

Also, the ability to specify format options (such as PNG compression level) would be very nice. At the very least, defaulting to normal png compression when exporting (as opposed to none) would be good.

It always the the full PNG compression provided by FreeImage (there are no levels, and it's lossless anyway.) The problem is that 16 bit heightfields don't compress much because they contain too much noise, i.e. there are no consecutive pixels of the same value. If you don't believe me on the compression thing, try saving an image that contains areas of solid colour, like a screen-cap of the design map, and compare with a bitmap. I get around 80:1 compression.

Cheers,
Aaron.

[aeyr]

Oh, awesome, the preference setting works great. I could've swore I had set that before and it didn't, but maybe it was on one of the like 6 builds I've got currently.

Looks like you're right about compression. I had been running a little tool I wrote on the pages and it was automatically converting to 8-bit despite my telling it to keep 16. mutter.

Thanks!

One last thing: for the far edges that don't have extra pages to copy data from, it'd be better to duplicate the edge values rather than have a row/column of 0's. It messes with dynamic LOD stuff when the curvature of a tile on the edge is way out of whack due to a strip of 0's. (It also looks a bit better. Heh)

Oh, and I just love your forum avatar, btw. Bebop rocks.