"blocky" imported heightfield bitmaps (comments)
by Andy · in Torque Game Engine · 03/19/2004 (11:46 am) · 9 replies
I imported to my mission a heightfield bitmap I created with Bryce 5. The "usual" Bryce heightfield export for a terrain object is a greyscale bitmap the same size as the resolution associated with the terrain object. I converted the greyscale bitmap to PNG24, dropped it into the heightScripts directory, and it imported correctly.
In-engine my terrain renders much more "blocky" than other terrains I have seen. I checked the code, and now I understand why my terrain is blocky.
The relevant routine appears to be Terraformer::loadGreyscale(), and the code fragment is:
Much to my surprise, the terrain engine supports much higher resolution than what I was expecting. For an imported bitmap, it's (roughly) 14-bits of green, 7-bits of red, and 2-bits of blue.
I'm still thinking about the best way to take advantage of this capability without messing up my workflow too much. Bryce can also export the terrain as a mesh (DXF is an option, I believe), so I should be able to create a tool that reads the Bryce-exported mesh, and generates a color bitmap from each vertex in the map.
Are others importing terrains from other tools? If you are, what are you using and why?
In-engine my terrain renders much more "blocky" than other terrains I have seen. I checked the code, and now I understand why my terrain is blocky.
The relevant routine appears to be Terraformer::loadGreyscale(), and the code fragment is:
for (S32 y=0; y<blockSize; y++)
for (S32 x=0; x<blockSize; x++)
{
U8 *rgb = bmp->getAddress(x,(blockSize-1)-y);
// compute the luminance of each RGB
dst->val(x, y) = ((F32)rgb[0]) * (0.299f/256.0f) +
((F32)rgb[1]) * (0.587f/256.0f) +
((F32)rgb[2]) * (0.114f/256.0f);
}Much to my surprise, the terrain engine supports much higher resolution than what I was expecting. For an imported bitmap, it's (roughly) 14-bits of green, 7-bits of red, and 2-bits of blue.
I'm still thinking about the best way to take advantage of this capability without messing up my workflow too much. Bryce can also export the terrain as a mesh (DXF is an option, I believe), so I should be able to create a tool that reads the Bryce-exported mesh, and generates a color bitmap from each vertex in the map.
Are others importing terrains from other tools? If you are, what are you using and why?
#2
Quick question here.. I noticed you mention that you'd exported a heightmap from Bryce for use in Torque...
I was, just last night, tearing through that program trying to figure out how to export just a heightmap, and cannot, for the life of me, figure it out. I'm using Ver. 5 so it should be available. The only options I found were to export the actual 3D mesh along with the skin, etc...
Which option am I looking for in Bryce to get the heightfield out?
I really appreciate any help with this.. Thanks!
Mike
07/30/2004 (5:51 am)
Hi all..Quick question here.. I noticed you mention that you'd exported a heightmap from Bryce for use in Torque...
I was, just last night, tearing through that program trying to figure out how to export just a heightmap, and cannot, for the life of me, figure it out. I'm using Ver. 5 so it should be available. The only options I found were to export the actual 3D mesh along with the skin, etc...
Which option am I looking for in Bryce to get the heightfield out?
I really appreciate any help with this.. Thanks!
Mike
#3
Keep Bryce and PS open at the same time. From the Bryce screen that shows the terrain as a greyscale, just hit ctrl-c and switch back to PS. ctrl-v and you can now 'adjust' it to your hearts delight.
Funny how that author used 3-4 pages to say this. Paid by the word perhaps? :)
07/30/2004 (10:25 am)
Posted in GD mag some years ago....Keep Bryce and PS open at the same time. From the Bryce screen that shows the terrain as a greyscale, just hit ctrl-c and switch back to PS. ctrl-v and you can now 'adjust' it to your hearts delight.
Funny how that author used 3-4 pages to say this. Paid by the word perhaps? :)
#4
Thanks!
Mike
07/30/2004 (10:49 am)
Ahh.. interesting.. I was thinking of doing the whole Alt-Ctrl-PrintScrn approach.. I'm sure that'll work just as well, tho'.Thanks!
Mike
#5
A program that would use this range would be excellent. Maybe a 3d program that can visualize the map to the proper relative scale. Then the program would save in the format doing the reverse calculations as described above. When Torque got a hold of it we would have a very high resolution height map.
Is there any program other than Torque itself that takes advantage of this resolution?
Edit: Actually it would not be the reverse calculation to get the proper data to Torque. You would simply place the upper 8-bits in Green, the middle 8-bits in Red, and the last 8-bits in Blue. The code above just weights the data according to bit location. It is essentially placing the bits into the proper location. Instead of doing it by bit location, it is doing it by power.
Thanks,
Frank
12/12/2004 (10:06 pm)
I don't think Andrew's original question was answered. Yes, you can use a regular bitmap program to build the height map. However, Torque can handle way more than 256 (8-bit) worth of height resolution. The actual range of heights is 0 to 16,777,215 (24-bit). A program that would use this range would be excellent. Maybe a 3d program that can visualize the map to the proper relative scale. Then the program would save in the format doing the reverse calculations as described above. When Torque got a hold of it we would have a very high resolution height map.
Is there any program other than Torque itself that takes advantage of this resolution?
Edit: Actually it would not be the reverse calculation to get the proper data to Torque. You would simply place the upper 8-bits in Green, the middle 8-bits in Red, and the last 8-bits in Blue. The code above just weights the data according to bit location. It is essentially placing the bits into the proper location. Instead of doing it by bit location, it is doing it by power.
Thanks,
Frank
#6
12/12/2004 (10:21 pm)
Id be willing to give a try at making a program to handle that kind of stuff, if its just "simple" terrain editing or importing/exporting tool. The only drawback really is that it would be a DOS based compiled QBasic program.
#7
12/14/2004 (10:48 pm)
The TSE terrain code has support for importing a 16bit raw file right now. It would be trivial to write a simple function in TGE load a similar file... And Photoshop can edit them (although not very well), and a lot of DEM packages can, too... 
#8
I'm assuming this range issue can be addressed in code, but we are fine with the workaround here. It is relatively easy to address in photoshop by 'clamping' the levels to the darkest and lightest pixels and applying a blur as suggested above to remove any banding that may have been produced by the level clamping. Also, if using photoshop, consider working in a 16 bit greyscale image until final save, then reduce to 8 bit, blur slightly if needed to remove any banding, then save.
-Jameson
12/16/2004 (7:05 am)
I have not looked into the relevant code, but our main texture/environment artist (Brandon Pierce) and I were having similar 'blocky terrain' issues. We were generating 8 bit greyscale out of photoshop as the terrain maps, saved out as .png. We found that to use all 256 levels provided by the 8 bits we needed at least one full black pixel (0) and one full white pixel (255) in the image. After ensuring our terrain bitmaps had this, they smoothed right out no problem. We also found, after using this solution, that using a 24 or 32 bit image made no real noticable difference in the 'smoothness', but that has not been tested thoroughly by our team.I'm assuming this range issue can be addressed in code, but we are fine with the workaround here. It is relatively easy to address in photoshop by 'clamping' the levels to the darkest and lightest pixels and applying a blur as suggested above to remove any banding that may have been produced by the level clamping. Also, if using photoshop, consider working in a 16 bit greyscale image until final save, then reduce to 8 bit, blur slightly if needed to remove any banding, then save.
-Jameson
#9
The utility probably can't read *all* .dem's correctly, but it works well enough for my purposes, and the terrain is nowhere near as blocky in-engine as it is if you try to use an 8-bit greyscale. The inner loop of the converter maps the min & max of the elevation data to the range 0x000000 .. 0xffffff (8-bits per R, G, and B) using the same ratios listed at the top of this thread.
To get Bryce5 to export a .dem of a terrain object:
1. select the terrain object.
2. File->Export Object, and then select "USGS DEM Files (*.dem)" in the combo control of the save dialog box.
If the resolution on your terrain object is 256x256, you'll get (in DEM-lingo) 256 profiles of 256 elevation samples each.
12/16/2004 (9:30 pm)
As far as using Bryce5, I eventually wrote a conversion utility that reads a DEM-format file and writes out an RGB24 PNG (no alpha). Bryce5 can export a terrain object to several formats, and .dem looked like it was the simplest to convert to a .png.The utility probably can't read *all* .dem's correctly, but it works well enough for my purposes, and the terrain is nowhere near as blocky in-engine as it is if you try to use an 8-bit greyscale. The inner loop of the converter maps the min & max of the elevation data to the range 0x000000 .. 0xffffff (8-bits per R, G, and B) using the same ratios listed at the top of this thread.
To get Bryce5 to export a .dem of a terrain object:
1. select the terrain object.
2. File->Export Object, and then select "USGS DEM Files (*.dem)" in the combo control of the save dialog box.
If the resolution on your terrain object is 256x256, you'll get (in DEM-lingo) 256 profiles of 256 elevation samples each.
Torque Owner Nicolas Quijano
I use a standard 8 bit greyscale image saved as a .png.
Simple, ain't it ?
Blocking might be due to banding, or some other reasons : if you export a color heightfield from any apps as 8 bit color (256 colors), you'll probably end up with banding/blockiness.
Desmond Fletcher talks about applying a gaussian blur on your image before saving it to eliminate banding, but that's because he's using a topographical image as the basis for his example, on his site (holodeck something, don't have the URL handy)
HTH