I’ve been experimenting with tessellation and displacement for the past week, and I’ve finally run into a nut a little too difficult for me to crack. =P
I’m attempting to import the ZBrush 4R3 VDM diagnostic mesh into UDK, and implement it with tessellation. For anyone unfamiliar with this, here’s the page:
I’m going to take a wild guess and assume they weren’t thinking about UDK when they put this together, since the diagnostic mesh itself is to large to import in one piece. I split the mesh into two pieces in maya, saved it out as an FBX, and imported it into UDK. For some reason, it imported as spaghetti. I still haven’t solved this.
My next issue lies with the map itself, as it’s in the format of an .EXR file. I found a thread on polycount;
which discussed rendering out two seperate maps from xnormal, and then modifying them in photoshop, and putting everything back together in the material editor. I’m having a tough time figuring out how to accomplish this with a file that isn’t already split into positive and negative. I imagine it involves manipulation of channels, inversion, and formatting in photoshop, but I’m having trouble figuring out exactly what needs to be done. I don’t really have a foundation knowledge of image formats yet. =P
Has anyone tried doing this yet? Could someone nudge me in the right direction with the image manipulation?
Zbrush also provides the map in a .PBM and .psb format, but I don’t yet understand which of these file formats would be easier to break down into smaller chunks and then piece back together inside UDK.
First off, you don’t need to import a dense mesh for testing. On the fly
tessellation allows you to tweak how many polygons you actually have.
Import a plane with like 8x8 quads and off you go. (Or even a single quad
but I vaguely recall some problems with that like limited tessellation
iterations or something.)
As for the texture data, UE3 seems to have a compression method for
high dynamic range data (RGB+E) but I’ve never used it. Chances are
that it will use huge amounts of memory which may or may not be
acceptable for you. If it’s a problem then you could start experimenting:
split channels into different textures (R, G, B, E all separate, RGB and E
separate) then play with textures sizes and compression methods until
the memory consumption / quality ratio becomes good enough.
Depending on the format you import data you might need to remap the
range of values. Common textures store stuff in the 0…1 range but for
normal/vector data you need -1…1 (plus exponent but don’t worry
about that just now). You can either change the Unpack Min property
in the Texture Properties window or do a lerp() in the material.
I’ll give it a try in the next couple of days using modo’s vector
displacement and see what can I come up with.
Short story: Vector displacements in UDK are practically useless.
Long story: I made a vector displacement based sculpture in modo 501.
The data was stored in a 32bit .exr file which I opened in Photoshop and
saved as .HDR to be opened in HDRShop 1.0. (That version is from 2001
and it was/is free for non-commercial use.) I saved the .HDR as .float and
imported in UDK.
I had some success using TC_HighDynamicRange compression and turning
on Full High Dynamic Range flag. However I couldn’t figure out how to use
the alpha channel: multiplying the RGB data with 10^alpha still had breaks
in the displacement. I experimented with stuff for two hours but the whole
feature is broken: changing texture properties either crash UDK or make the
displaced polygons stretch to infinity. The stretching remains even if I undo
my actions. Restarting UDK and/or rebooting sometimes helped sometimes I
had to reimport the same texture as a different asset.