Tutorial: Converting a DEM to a heightmap

[TrickyVein]

First of all, thanks for asking. I will try and help as much as I can. My final advice is to start over from the original BMP if something doesn't seem to be adding up.

 

The image itself contains no useful information for why the importation process isn't working, I'm afraid. I can also tell you that the vertical scale of your terrain is probably greatly exaggerated. Did you apply a gradient map? It looks as though your values range from 0 (black) to 255 (white). They should be between a dark and less dark shade of gray, for the heights to work out correctly in the GECK, like this.

 

As to how to select an area of interest from the full-scale BMP that you exported from VTP, I imagine that using the crop tool, rectangular select tool, or simply pasting into a new image with the correct dimensions will work in Photoshop. Pull guidelines to the center of your image from the top and side (with snapping on) to divide your 2048x2048 image into four quads that you can select and paste into new 1024x1024 images. Save each of these with the correct header and byte order (0 and IBM, respectively) with the correct file name (0_0, 0_-1, -1_-1, -1_0), with no '.RAW' suffix.

 

I do not elaborate very much on the things you describe. As you are probably finding out, it's a lot to keep track of, and there other tutorials and information out there. While I don't provide links to other tutorials, you can find out *everything* you need to know from reading through pages on the GECK wiki at bethsoft about worldspaces, heightmap editing, game units, LOD, and anything else that you're curious about.

 

This page is probably helpful if you're wondering just how large an area you should be working with: http://geck.bethsoft.com/index.php/Units

 

I can say that working on (i.e. sculpting, adding rock meshes and vegetation to and applying textures, etc) any area larger than a single quad is probably too much for one person. Real life has a tendency to get in the way of these things.

Edited May 11, 2012 by TrickyVein

[Jeux]

Alright. Started over with the base bmp. I did apply the gradient the first time, but I did not use correct value ranges. I figured that if I wasn't seeing the terrain clearly, I was losing detail...not the case at all. I did as you said, placing guidelines on the image to evenly divide it.

 

http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/RAWimageproblem-origin.jpg

 

I then manually started creating 4 new 1024x1024 images, naming them accordingly. Cropping each corner of the original bmp, I pasted and manually transformed/scaled each quad.

 

(0_0) http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/0_0.jpg

 

(0_-1) http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/0_-1.jpg

 

(-1_0) http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/-1_0.jpg

 

(-1_-1) http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/-1_-1.jpg

 

Seeing that each quad was 16 bit grayscale, with the proper gradient and Gaussian blur applied before the split, I exported each one to the "Heightfield" folder in the New Vegas "Data" folder.

 

I fired up GECK, created a dummy worldspace WITHOUT specifying any particular parameters (besides the name), and opened the worldspace up for heightmap editing.

 

Then I imported.....took about 30 seconds.....success.

 

http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/FreshlyImportedHeightmap.jpg

 

Previewed it, and of course it isn't without problems. First, as Dakcenturi already described earlier, there is a pretty nasty border clipping between each of the quads.

 

A clever workaround is to create a 2048x2048 image then cut => paste quarters of it into new 1024x1024 images when you're finished editing the 2048x2048 bmp.

 

I'm not sure if I follow. Could you elaborate? Or do you have any other alternatives/ideas?

 

Then the mountain region is pretty noisy, very sharp (in fact, all areas are to some degree). Your only solution to this would be to go back, start the process again from the original bmp, and choose an EVEN CLOSER range of gray colors when applying the gradient. Trail and error, I suppose. I will post my results once I have done so.

 

http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/FreshlyImportedHeightmapPreview.jpg

 

Because I didn't feel like going back to photoshop and doing it all over again, I played with the GECK's heightmap tools to try and soften it up a bit. I'll definitely have to go back to photoshop haha

 

http://i1238.photobucket.com/albums/ff500/jeux793/Radiant%20Flux%20Screens/SoftenedHeightmapPreview.jpg

 

I do not elaborate very much on the things you describe. As you are probably finding out, it's a lot to keep track of, and there other tutorials and information out there. While I don't provide links to other tutorials, you can find out *everything* you need to know from reading through pages on the GECK wiki at bethsoft about worldspaces, heightmap editing, game units, LOD, and anything else that you're curious about.

 

I am no stranger to worldspace design. I have a fair grasp on just about every one of the subjects you mentioned, and then some. Check my sig for my current project. What I meant was...it felt as though you were explaining without relating it back to proper worldspace design itself. Example, I looked at the amount of terrain chunks of this new worldspace WITHOUT any specified parameters (cell size, usable dimensions, land or water level, etc) just so I could get an idea of what LOD generation would take.

 

My imported heightmap with untouched/unspecified worldspace parameters: 404 terrain chunks

 

Zion Canyon, Big MT and Divide World worldspaces: 336 terrain chunks (I wonder how they get them exact)

 

New Vegas: 1360 terrain chunks

 

It takes me about 1-2 hours to generate LOD for a worldspace the size of about 30-50 chunks, and 5-8 hours for 100 chunks. I wonder how long for 400 chunks...

 

Another thing. Land level. I would want to declare the land and water level before I import the heightmap. Here's one reason why:

 

1) There is a nasty water clipping bug in-game which I STILL have yet to figure out. Basically, the natural water level of worldspaces tend to sometimes clip, and you will never know it is problematic until you finish establishing/designing the worldspace and test it out in-game. See here: http://geck.bethsoft.com/index.php/Category:World_Spaces

 

The only given solution so far...which I have yet to DEFINITELY confirm myself....is to set the water height for the worldspace above 10500 units.

 

So would changing the height of the land above or below the default -2048.0000 alter the outcome of the import in any way, besides the physical height (obviously)? Like...would the terrain be any more or less rigid? I would imagine not, but still...

 

Hope all of this made sense. Thanks, I will experiment further later on. I'd REALLY like to get this down to a science, for it would be just amazing to have highly detailed and structured land masses like the ones in your initial post. Those 5 screens are what keep motivating me to try again and again.

[TrickyVein]

I am no stranger to worldspace design. I have a fair grasp on just about every one of the subjects you mentioned, and then some. Check my sig for my current project. What I meant was...it felt as though you were explaining without relating it back to proper worldspace design itself. Example, I looked at the amount of terrain chunks of this new worldspace WITHOUT any specified parameters (cell size, usable dimensions, land or water level, etc) just so I could get an idea of what LOD generation would take.

 

My imported heightmap with untouched/unspecified worldspace parameters: 404 terrain chunks

 

Zion Canyon, Big MT and Divide World worldspaces: 336 terrain chunks (I wonder how they get them exact)

 

New Vegas: 1360 terrain chunks

 

It takes me about 1-2 hours to generate LOD for a worldspace the size of about 30-50 chunks, and 5-8 hours for 100 chunks. I wonder how long for 400 chunks...

 

Another thing. Land level. I would want to declare the land and water level before I import the heightmap. Here's one reason why:

 

1) There is a nasty water clipping bug in-game which I STILL have yet to figure out. Basically, the natural water level of worldspaces tend to sometimes clip, and you will never know it is problematic until you finish establishing/designing the worldspace and test it out in-game. See here: http://geck.bethsoft.com/index.php/Category:World_Spaces

 

The only given solution so far...which I have yet to DEFINITELY confirm myself....is to set the water height for the worldspace above 10500 units.

 

So would changing the height of the land above or below the default -2048.0000 alter the outcome of the import in any way, besides the physical height (obviously)? Like...would the terrain be any more or less rigid? I would imagine not, but still...

 

Hope all of this made sense. Thanks, I will experiment further later on. I'd REALLY like to get this down to a science, for it would be just amazing to have highly detailed and structured land masses like the ones in your initial post. Those 5 screens are what keep motivating me to try again and again.

 

Yeah, so I'm probably just as knowledgeable or not even as knowledgeable as you when it comes to these things.

 

1) The New Vegas worldspace covers an area far in excess of the playable area. It seems really stupid. You can disable the invisible walls and scale mountains in the Mojave only to see vistas of unused terrain just sucking up memory resources. 1360 terrain chunks indeed.

 

2) I don't know how to get the correct height values to correspond to an absolute, correct water level. I just use values from existing worldspaces for land height and water height. Nowhere have I seen anyone provide an adequate explanation for any of the numeric values that are used in-game, and what's appropriate to use for a custom heightmap.

 

3) I am SUPER happy you got your images to import, and thanks for sharing those examples! It is very much a trial and error process through photoshop. It's surprising just how little contrast RAW images should appear to have in order to look suitable inside of the editor.

 

I have never had issues with the quads not 'meshing' together at their boundaries. Weird. This is what I do. Work on your 2048x2048 total area as if you were going to import it into the editor. Cut and paste 1024x1024 pieces of it into new files and import these instead. Hope this helps.

[Dakcenturi]

I did the above with the 2048x2048 and it worked perfectly only instead of grid lines I put in 4 1024x1024 boxes and selected the boxes and copied the terrain underneath. I still haven't gotten it to impot into the GECK with smooth terrain, but I may just need to mess with it some more. The smooth tool seems to work out really well for me though except on the borders of the map, for some reason it just won't do any smoothing in the border areas.

 

Here is an ingame shot with LOD generated. Need to figure out how to make the LOD more visible and not so bright if there are any suggestions:

 

http://www.thegeekenders.com/resources/FO2161/ScreenShot1.jpg

[Jeux]

Yeah, so I'm probably just as knowledgeable or not even as knowledgeable as you when it comes to these things.

 

Oh! I hope I didn't sound snobbish or stuck up! I was not trying to come off that way, I still have much to learn anyways (hence why I'm here).

 

I have never had issues with the quads not 'meshing' together at their boundaries. Weird. This is what I do. Work on your 2048x2048 total area as if you were going to import it into the editor. Cut and paste 1024x1024 pieces of it into new files and import these instead. Hope this helps.

 

That's exactly what I did the second time around, funny enough. That exact process...maybe I didn't word it right the first time, apologies :sweat:

 

Anyway, I'm going to give it another go tonight or so.

 

Need to figure out how to make the LOD more visible and not so bright if there are any suggestion

 

Did you properly place the generated LOD textures in the landscape folder? Is your worldspace's weather fog color set to white or something? (If so, change the color AND expand the "far" fog distance)

 

That's all I can think of right now...pretty strange. Usually land color irregularities end up purple (missing textures)

[TrickyVein]

I've had snow-capped mountains happen to me as well. Things also get screwy when you generate LOD textures for world objects then continue working on your worldspace.

 

Yep, same problem. These are just images I've had lying around.

 

Here, and here.

 

And here you can in the distance that the terrain chunks are textured with LOD textures from other objects instead of terrain textures. But until you finalize your worldspace and get ready to publish, generating LOD is a preemptive measure anyway. It's just to help guide the design process until you decide to finalize everything.

[Dakcenturi]

Forgot the step of moving the LOD folder out of Source\Textures TGA\landscape and putting it in the correct location. Seems to have resolved it aside from the snow caps you mentioned :P

 

http://www.thegeekenders.com/resources/FO2161/ScreenShot2.bmp

[TrickyVein]

Also, important side note: the gradient map is applied across the full range of values in your image. If you divide your 2048x2048 image into four 1024x1024 images - corresponding to each quad - and then apply a gradient map to each one separately, the relative heights will be different between each of your four quads, and you will end up with a situation like you show here, Jeux.

 

Also, you're wondering which absolute value corresponds to which height value in the GECK?

 

For instance, a value of 0 in the heightmap (black) corresponds to what default height?

 

From the GECK wiki:

 

It's important to know how the height units in the heightmap editor relate to the actual terrain elevation when the map is saved to the plugin. Water level (defaults to z=0 in exterior cells) corresponds to z=4096 on the height map. Moreover, all differences from this value are doubled in the generated terrain. For example, z=4196 doesn't give a terrain height of 100, but 200 instead. Following this formula, the default height in the heightmap editor (3072) results in an ocean depth of -2048 units.

 

As confusing as this is, I don't think it sheds any light on what values your RAW image should have to contain in order to correspond to certain default heights within the editor. A z-value of 4096 within the heightmap does not correspond to a pixel value of 4096...I don't think.

 

It should be possible to figure out how it scales. Later on I'll try importing a heightmap of completlely null (black, 0) values and see where it ends up by default in the editor. Then try the same with 50% gray and other values. This should make it less of a guessing game as to what the exact range of values in your RAW images should be.

Edited May 12, 2012 by TrickyVein

[Jeux]

I actually applied the gradient and Gaussian blur before splitting the images into quads. I tried the process again, using closer ranges of values within gray. Upon importing, and as expected, the terrain was much less exaggerated in terms of height and noise. However, the border problem remained. I'll experiment again Monday (tomorrow is Mother's Day in the States, going home)

 

While I never explored the specifics, I have learned of the "doubling" of the height units upon saving heightmaps the hard way. I'd manually generate, draw, and edit a heightmap...thinking I have a good looking island...then upon saving for editing via the render window, the terrain is either double the height I planned or completely submerged in water! I have had to do a good bit of experimenting with both the heightmap editor's "height color?" values and the worldspace land and water values. I still don't fully understand the relationship between the two, so up until this point I would just work in good faith, hope the heightmap generates something good for me, and adjust the worldspace water height after generation/saving.

 

If you could figure out how it scales, it would make working with the heightmap in general less of a "....oh well" guessing game. And, of course, we would know exactly what ranges of values to have in our RAW images...(more precise gradient, ya? Or am I just rambling here, trying to sound like I know what I'm saying when I don't? haha)

[Jeux]

Forgot the step of moving the LOD folder out of Source\Textures TGA\landscape and putting it in the correct location. Seems to have resolved it aside from the snow caps you mentioned :P

 

http://www.thegeekenders.com/resources/FO2161/ScreenShot2.bmp

 

 

Like I said before, I would have thought your terrain would have been purple :happy: But you guys still don't know what's up with the "snow cap" on the LOD meshes?