Height Maps Issues

FoeJred

Hi there, im new here, but looking foward to getting involved with the community. Was hoping some one out there might be able to help me out with a problem im running into. I am currently trying to make a UDK environment using Choco's amazing Terrain tutorials
[ame="http://www.youtube.com/watch?v=EtR-4vA6wAg&feature=plcp"]How to import a terrain to UDK - YouTube[/ame]
[ame="http://www.youtube.com/watch?v=EtR-4vA6wAg&feature=plcp"]How to import a terrain to UDK - YouTube[/ame]

I try my best to follow his examples. but for some reason my levels just don't turn out like his. When i import my World Machine height maps to UDK, I loose alot of detail in the surface, And i am left with alot of blocky riggid geometry. This also happens when i import into Max, mudbox and even when i import back into world machine, this makes no since to me. :poly127: I render out 4096 height maps just like choco, and even re-rendered a 1009 for the udk as a TGA file just like he does. What am i missing here, why do his level import nice and clean?? Anyone know?

metalliandy

It's because you are using an 8bit map.
TGA (or any 8bit format) cannot store enough information to reproduce a smooth transition because it can only have 256 levels between black and white.
You need to be using at least a 16bit image, such as tiff, png or even OpenEXR or raw to get anything decent when using heightmaps.

FoeJred

Thank you!! I will give this a shot, i didnt know that about TGA's

Santewi

FoeJred wrote: »

Thank you!! I will give this a shot, i didnt know that about TGA's

It applies to all images. 8-bit image is the same as 2^8 = 256. 16-bit image is 2^16 = 65565, so 65565 different levels of height in this case.

FoeJred

This is eye opening, lol I used TGAs for everything in my last project.

metalliandy

I moved over to a full 16bit workflow a while back and only use 8bit images at the very end of a pipeline if I must. It's the best way to preserve information and allows for a much larger and less destructive tweakable range in many cases too. Things like levels adjustments are much less destructive in 16bit.

Santewi

However, UDK converts the textures to 8-bit. I don't know if some of the compression settings let you keep the image as 16-bit, though.

metalliandy

Santewi wrote: »

However, UDK converts the textures to 8-bit. I don't know if some of the compression settings let you keep the image as 16-bit, though.

You have to use 8bit in UDK yes, but It's best to keep the highest bit depth that you can before importing. All my source textures are always 16bit until the last possible minute, where I down sample then to 8bit in PS and import as usual.

FoeJred

Santewi, voiced my concern, because UDK uses 8-bit, i always used TGAs, and bmps, good to know that 16bits the way to go though, do you happen to know what cryengine uses? 8bit or 16bit?

metalliandy

Both CryENGINE 3 and UDK use 8bit, though CryENGINE has much better compression than UE3 (currently at least) due to a modified 3Dc/BC5 encoder. The compression is much cleaner than the DXT1/5 or the BC5/3Dc encoder that is currently available in UDK.
http://www.crytek.com/download/AdvRTRend_crytek.ppt

e-freak

you can import 16 bit into Cryengine to avoid stepping like this. However, in any case, it might be a good idea to just run a very weak smooth over your terrain, to make sure it's all settled.

personally I wouldn't use 16 bit for anything but a heightmap bake in production - it just takes too much time to work with 16 bit files and you will always have to go back and forth with shit. 8 bit is more than enough detail in 99% of your daily production artwork on games.