Resampling HF and some advice

[Rummy]

A question for those who might answer or offer advice for this problem of mine. First I should say that I enjoy this program more and more, great work and support. Now my questions:

My height field was generated from 3arc second STRM data and our intended coverage area encapsulates about 720km. I have to cram that onto a 131072 plane. 3arc second is about 90meter resolution so I have to upsample by a significant value (16). The process I have tried using is to resize my imported HF on export from the 8192px* to 131072 as a HF mosaic. Ideally I need tiles themselves of 8193 * 8193 but I don't get very far with a tile that size so I left it at 512*. Is this the correct way?

I would also like to use L3DT to generate an attribute map which I am inturn using for the game engines texture correlation and placement, and would like to do that with a HF chunk of 8193px. So, it would be great to keep thing in that size unless I could solve my next problem. Presently, I have been upsampling one at a time after cutting the map up without resizing, and while this works fine, I am running into slight differences in my elevations at the seams. This certainly is my error however I have tried border duplication, horizontal scale is the same so it must be my vertical scale that is at fault? I'm using a .png with this pS plugin http://www.fnordware.com/superpng/
and assume I am just letting it span the grayscale by leaving it default?

Any help would be appreciated.

[piratelord]

Sorry, I don't understand most of what you've said, but I think I know the answer.

L3DT sets the max altitude of the map to your brighest colour on your imported heightmap by default.
I had the same problem, and Aaron kindly added a feature which made solid white the max altitude instead.
It's under the file preferences, but can't tell you off the top of my head.

[Rummy]

Ah, ok span grayscale = false I bet? If so thanks for that. Wonder if I need to also handle that in export since I'm having to use .png with a conversion to tiff in Photoshop.

As for the resizing the heightfield all at once, if this solves my seam issues I can handle it other ways since the larger I can make my HF tiles the better (their not really tiles just large blocks to insert into game engine as engine uses its own tiling system).

[Aaron]

Hi Rummy,

Sorry I'm late joining this party.

Ideally I need tiles themselves of 8193 * 8193 but I don't get very far with a tile that size so I left it at 512*. Is this the correct way?

Tiles as large as 8193x are undesirable in L3DT because it usually holds a few (say, 9) tiles in memory at one time. Nine 8193x heightfield tiles equals a bit over 2Gb of RAM, which is bad. Smaller tiles are nicer, but if they get too small, then you’re overdoing the disk-paging and underutilising RAM. 1024x is probably the sweet-spot, but the default is 512x because it’s ‘safer’ for slightly older computers with less than a gig of RAM.

So, what I recommend is import your heightfield, up-sample it to the required size (using 1024x tiles), generate your attributes map (again using 1024x tiles). At this stage, everything will be nice and self-consistent.

I can’t say exactly at what point in your process the scaling is being messed up, but this is always a problem when modifying tiled image heightfieds, since the files don’t contain any real-world-units conversions. A suitably formatted TIFF might to the trick, since they can store such data, __but__ I don’t have a TIFF plugin at hand.

Anyhoo, everything should be cool if you generate your HF/AM, then export them as mosaics as 8193x tiles. L3DT will, or at least should, keep the scaling consistent across all tiles when exporting. I may need to re-jigger (or at least check) the export code to make sure this tile size is supported. It’s certainly feasible, but I simply haven’t tested it.

Oh sod, I just realised you’ll need the ‘grow tiles by one’ option too, as I’m assuming your 8193x8193 tiles share a 1px border to avoid seams. That’s going to require a slight change to that plugin, which also needs to be handle really large tiles in a slightly smarter way.

Anyway, changes are now on the to-do list.

Cheers,
Aaron.

[piratelord]

Yeah, the 1 pixel overlap for the Torque atlas is a right royal pain, but understandable for landscape tiles

[Rummy]

Thanks guys, this is certainly getting me on the correct path. I do in fact need to compensate for the overlapping pixels. Should I duplicate the borders before I attempt this? Also should I just wait if there are limits to the grow tiles by1 plugin, or can I just export a pixel larger?

Re. the scale , yes I'm sure it is getting duffed when I convert the .png to tif. I don't know if the source is public but super .png (the plugin I posted) will store meta data but even if I maintained it I'd still loose on convert? A geotiff would be great but the game engine requires borders to any image I insert so I have to use an image editor to add those. In other words without the geotif plugin for photoshop meta data is nuked when you open it in Photoshop....atleast CS2.

thanks for the suggestions, I shall give them a go.