Terrain import

[monks]

Hey Aaron, we spoke over at ME-DEM regarding the design map res and importing the base DEM (or terrains).
Unfortunately I've kind of lost that thread- can't find it- so could you remind me where we were up to with that?

I did try and import a terrain, but I really want to make sure I've got a handle on this.


Cheers,
monks

[Aaron]

Hi Monks,

My memory is a little shady right now, but here goes:

What I think I was proposing was a way to up-scale tiles in the base DEM by a factor of 10, which I understood to be a/the current task.

So, take any 1000 x 1000 pixel tile, for example, and import it as a design map (see here).

Set the ‘File->DM sample rate’ to 2.

Click 'next >>', set whatever design params you like, and click OK.

Manually modify the design map to suit your preferences.

Now, rather than generate the heightfield normally, use the 'Operations->Heightfield->Generate preview' option to make the heightfield. I'll just reiterate that: generate the heightfield using the preview, not the normal way. For a starting map of 1000 x 1000, this will give you a final heightmap of 8000 x 8000, and you also have more precise control over the final shape using the deisgn map.

Anyway, once you've got your 8000 x 8000 heightmap map, you can easily resample it to get the 10,000 x 10,000 size (Operations->heightfield->resample map).

Now, to split it into 1000x1000 tiles again, use the 'Operations->Active map->Split to mosaic' option, and set the 'tile size' to 1000. This will give you 10x10 tiles of 1000x1000 pixels, based on your original 1000x1000 tile.

Is this sort of what you had in mind?

Cheers,
Aaron.

[monks]

Right, I'm having to get my hand back with this as well...so bear with me.

There wiill be two potential situations where a terrain will be imported to L3DT for MEDEM

1. To take advantage of L3DT's Design Map stage: build from scratch.(It will not actually be building from scratch, because you would not start out with a blank heightfield).

2. To apply any of the later stages that L3DT offers (potentially erosion to output textures), to a terrain already designed, designed+eroded, etc..(essentially a finished heightmap)


Taking 1. This is the full integration of L3DT into our workflow.

I initially thought that your example figures were 10x too large (which confused me at first), but I think I get it now.

I'm taking the minimum requirement here: the smallest element of our terrain: a 100 px tile. (The apps will be capable of importing larger tile sets obviously: so a 1K tile-set import that you quoted will also be possible.)

We will be importing a 100 px tile. It will need to upsized to a 1K pixel tile (again, it could be upscaled more while actually within the app to get a better res, just as long as it is output back to ME-DEM as a 1K tile- ie 20m res). If L3DT can take care of all of this rescaling so much the better.

Stick with the simplest case: the user upscales the tile to a 1k px square heightfield within L3DT.



So, I followed your instructions, and this is what I got:

(1) I imported a 100 px tile via File > Import Design Map (.bt, with world scale set to 200m)

Import Design Map Wizard:
2/3: File-> DM sample rate: 2

So this takes every 2nd pixel and uses it for the design map pixels: (so we should have a 50 x 50 Design Map)

3/3 Design Map parameters:
The application of these parameters I'm not fully understanding right now...so I turn them all to zero. Could you detail the rammifications of this dialog?
I leave everything else at defualt.


I do indeed get a 50 x 50 Design Map: great
OK, the scale is wrong, but so what?- we resample later.

(2) This is where we manually use the Design Map Pencil to do our stuff.

Operations > Heightfield > Generate Preview (as opposed to Generate map).

You said that there was a difference to the inflation routines between those two operations, what are they? (looking at the resampling dialog, it seems that the prev defaults to a smaller upscaling: x8, the full non-preview to 32, is that right?)

Before we continue in L3DT or export out of L3DT as a heightmap, we need to Resample map and Change horizontal scale.

Operations > Heightfield > Resample map: in this case, to 1K x 1K

Operations > Heightfield > 20m.

(3) We export the active map as a heightfield or go on to generate all of the L3DT goodies.

Now I get it! I had completely forgotten about the import design map feature on heightfields: very nice! Also, I was overlooking resampling- it really makes no odds.

The crux for MEDEM is stage (2). How to best use the info imported into the apps.

monks

[Aaron]

Hi Monks,

3/3 Design Map parameters:
The application of these parameters I'm not fully understanding right now...so I turn them all to zero. Could you detail the rammifications of this dialog?

These are the default mask values for the roughness/cliffs/erosion/etc routines that are applied when you generate the heightfield (shoddy demo here). If you leave them at zero, you will have a very smooth and boring heightfield.

I do indeed get a 50 x 50 Design Map: great
OK, the scale is wrong, but so what?- we resample later.

Oops, I'll look into it.

You said that there was a difference to the inflation routines between those two operations, what are they? (looking at the resampling dialog, it seems that the prev defaults to a smaller upscaling: x8, the full non-preview to 32, is that right?)

Relative to the original tile import, yes. Relative to the design-map it's 16x for the preview and 64x for the regular algo. The main difference is I've chopped out a bunch of inflation levels (to get the smaller size), dropped some erosion, and ditched the volcano/mountain/plateau overlays in the preview.

Cheers,
Aaron.

[monks]

Oops, I'll look into it.

I'm not sure if there is a problem with the scaling Aaron. Did you find one ?

monks

[Aaron]

Hi Monks,

The scaling assumed a 64x scale-up from design map to heightfield, which is OK if you're using the regular 'Operations->Heightfield->Generate map' option, but is incorrect if you're using 'Operations->Heightfield->Generate preview' to generate the heightfield (as this uses 16x). There's no easy quick-fix for this, but I've scheduled some changes for v2.4a (later in the year) that should make this all work properly (64x will no longer be hard-coded).

Cheers,
Aaron.

[monks]

Great! I think it's best to avoid hard wiring, much as was pointed out recently with the ME-DEMcentric 100 px tile naming convention. The more arbitrary the better- as Carmack was at pains to point out with his MegaTextures over any game object. I'd also like to see the move away from powers of 2 in terrain sizes.

monks

[Aaron]

Hi Monks,

I'd also like to see the move away from powers of 2 in terrain sizes.

I don't think we'll ever see the end of powers of 2 in terrain sizes. Side-lengths of 2^n (or 2^n+1, for that matter) are extremely useful for things like subdivision, which is used in most level-of-detail terrain renderers, and also in most fractal terrain algorithms. You can, in some instances (but not all!), hack the algorithms to work with non-power-of-two sizes (or else pad the input and clip the output), but this makes them slower and usually more memory-intensive.

For example, L3DTVi2 doesn't require 2^n sizes for input, but internally it converts the terrain into tiles of 2^6 or 2^7 (64 or 128, I can't remember which), and clips any surplus edges during rendering. It's not very neat code, though, and it's a little buggy in places.

As for L3DT; the fractal algorithm is stuck with 2^n, the perlin can do any size (no subdivision involved), and the design/inflate algorithm (which uses subdivision) can do (m x n) * 2^6, where m and n are independent. Later this will be changed to (m x n) * 2^b, where b will probably be in variable in the range of 3->9 (that's DM blocks of 8x8 to 512x512 HF pixels). I could also write another variant of design/inflate with unconstrained sizes, but it would be an awful lot slower, as I’d have to replace fractal interpolation with cubic interpolation. Ye-olde L3DT 1.5 used this algorithm, but it was about 10x slower than the current situation.

Edit: Oh, I should add that in the 'design map size' wizard, you can specify non-power of two sizes for the design map. The slider-bars step in powers-of-two (for convenience), but the edit-boxes accept any positive integers up to the max size limit. This may not have been obvious to users.

Cheers,
Aaron.