Vector Displacement maps in UDK(.float files)

EmAr

Hi!

I see similar threads were started but it's been about one year since the last one so I guess it's ok.

I'm trying to get some vector displacement maps into UDK. I think this should be working smoothly as there is even a corresponding compression setting(TC_VectorDisplacementmap).

The problem is with the file format(.float) UDK supports. It seems the only way to convert openEXR or floating point TIFF files into the .float format is to buy HDR Shop for 200$. Since there is no demo version of the program I have no idea whether it works. This page makes me think it's not the correct format:

Raw Float Format
This format is very simple. It is just a bunch of binary 32-bit floats in a file. There is no header, or additional structural information. Consequently, HDR View will prompt you for the specific format information (width, height, # channels, endian-ness) when you try to load a file in this format.

Does anyone know a way/program/photoshop plug-in to create UDK-friendly .float files for free?

An alternative solution I could think of, which is not very practical, is using 2 maps. One would contain the positive values of direction vector components, the other would contain the negative values. Then I could subtract one from the other to get proper direction vectors. Magnitude would still be a problem though, I could somehow combine the alpha channels of the two textures but yeah, I said it was not practical.

Thanks for looking. Any help is appreciated

Eric Chadwick

Norman3D used vertex colors to get vector displacement into UDK, http://www.polycount.com/forum/showthread.php?p=1472523#post1472523 , but it sounds like you still want a baitmap instead.

I know the Landscape tool can import RAW files from Photoshop, so maybe .RAW will work? I used 16 bit RAW for the heightmaps...

• To load heightmap RAWs in Photoshop, set the RAW importer to 1 channel and 16bits and IBM PC. To load the alpha map in Photoshop, set the RAW importer to 1 channel and 8bits.
• To save RAWs out of Photoshop: height maps should be Grayscale and 16 Bits/Channel (Image menu > Mode) and save as RAW (IBM PC), alpha maps should be Grayscale and 8 Bits/Channel and saved as RAW.

EmAr

Thanks for the suggestion UDK seems to ignore RGBA .raw files. It can be because I am exporting from Photoshop 6(not CS6) though.

I tried the two-texture thing and it seems to be working. Here's what I did:

In xNormal(tangent option is off):

- Render one direction map with X+, Z+, Y+
- Render another direction map with X-, Z-, Y-
- Save textures as TIFF files

In Photoshop:

- Change mode to 8-bit from 16-bit. This makes Photoshop clamp the values between 0 and 1, erasing the negative values.
- Now I have the negative component values(as positive numbers) in one texture and positive values in the other.

Then I subtract one texture's RGB from the other's in UDK and multiply the result with the alpha of one of the textures. It must also be multiplied with a constant.

Below is the resulting material and the original models in Max:



Still any suggestions are welcome. This does not look pretty enough :P

Eric Chadwick

I used CS5 with the November UDK, and the RAWs were specifically for importing Landscape layers. So my guess is they're not supported anywhere else but there.

I would also guess that .float files were added as a get-it-in quick feature, with minimal testing.

Another thread about .float... http://www.polycount.com/forum/showthread.php?t=79100

EmAr

Then I guess I'll have to wait until vector displacement techniques become more widespread

Thanks again.

Garrettorious

Have you experimented at all with ZBrush 4R3's new vector displacement map exporting?

http://www.pixologic.com/docs/index.php/Vector_Displacement_Maps

As you can see, they offer a "diagnostic" mesh and map. I tried to import the mesh into UDK and got a lot of funkiness going on. First off, it's meant for "diagnosing" applications like mudbox, maya, etc, so it was too high poly to import, and I had to split it up into two meshes.

When I did get it imported, the model was scrambled. I'm not sure if this was simply from the tri count, or if my conversion settings from obj to fbx are screwed up, or what. I do know that that as soon as I turned on tessellation in the material, one half of the imported mesh almost completely "healed", though it still had a few spaghetti lines. I'm having some trouble getting past this diagnostic step.

Do you guys think it's a matter of dividing the mesh up into smaller imports?

Also the diagnostic map included with zbrush is a .EXR, which as mentioned above, needs to be split up, and then put back together. Thoughts, ideas, name-calling?

EmAr

Maybe our problems are caused by the difference between the methods with which dX11/UDK and other high-res rendering applications handle displacement. One thinks it should be a pretty straightforward task to displace a mesh which is tessellated with flat tessellation but it seems to be not like that

Garrettorious

I have not studied your twist/bend shader work too closely, but it seems from that and from Norman3D's work, udk does have the ability to render vector displacement. If the problem is then the maps, it looks like you have the answer right here, with splitting them up in to digestible chunks, and combining them later. My point would be to figure out the correct export settings from zbrush into UDK.

I think with a material function, combining those two "half maps" would be no problem. I'm having some trouble understanding where the big problem is, probably because my knowledge of file formats in general is limited.

Is there a great deal of quality lost when the file is split?

EmAr

The quality loss is mostly due to the conversion of magnitude component(alpha channel) from 32/16-bit to 8-bit.

I decided to give Mudbox a try but I'm pretty sleepy right now I'll try it tomorrow.