Hi guys,
Just started to play about with using displacement maps in UDK and have come up against a few problems, I've checked out a few guides on how to create Displacement maps and how to make use of Tessellation but have come up against an issue that I'm not too sure how to fix.
seeing as this is an early art test I created a cylinder and beveled in a few sections, not exactly the most detailed of high poly models but thought it would be a good starting point. (See image below)
I baked a normal and a height map using xNormal and proceeded to make use of them in UDK, the height map didn't exactly appear to need any cleaning up so I left it as is. Unfortunately when I put my material containing the Displacement map on the cylinder I get these results.
I'm guessing the pinching in the side is from the seam of the unwrap, but the weird shape the cylinder takes puzzles me as it should deform from the original. Looking at the normal and height maps I can see some issues with the un-wrap and bake but I'm sure these wouldn't cause the issues I'm getting.
If any one can shed some light as to why this is happening it would be greatly appreciated.
PS. I baked the low poly containing a couple of turbo smooths, I read that it helps stop the model from ribbing while baking, but the model in UDK is not turbo smoothed.
Replies
Yes and no. It all depends on what you are asking your displacement to do for you, similar to normal maps. The big advantage of displacement maps is they actually deform the surface and silhouette. I have never used displacement maps for hard surface stuff actually, so you might want to wait and see what someone else says. My guess is that if you make the extrusion a little less extreme, and add a little taper to it you will get a much better result.
Edit, also be careful with image compression with your displacement maps. You can get banding sometimes so that could also be the issue.
So would I be right in assuming that most games will only make use of tessellation and displacement maps on key areas in a level to save on a FPS drop, or do they tessellate everything and thanks to tessellation working on distance to camera rendering they can get away with having most of the level tessellated?
I've attempted to try and get the DX11 version of Aliens vs predator showing its polycount or just a wireframe in game, to try and prove either of these thoughts, but unfortunately I've had no success with that or trying to find out anything online about poly-limits in a level while using tessellation.
Any help anyone could give would be appreciated. Cheers
I don't know if the tessellation performance (in UDK/UE3) is different for nVidia users, but at least for me using any kind of tessellation really kills the framerate.
We've got one guy with a GTX670, and two guys using GTX680's (including myself). Tessellation in UDK/UE3 isn't that performance friendly even on these cards. And enabling cascade shadow maps makes it terribly worse.
In general performance seems second rate in UDK DX11 vs DX9. We've seen that just enabling the DX11 renderer without using any of the features is usually around 15-20% slower in our scenes. So far we are not comfortable with supporting DX11 for our title. Unless anyone can shed some light on getting better DX11 perf???
If anyone has used Cryengine 3 for tessellation and Displacement mapping I'd be interested to know if they suffered from a similar drop in performance as I'd go try that engine out if it heralded a better performance than UDK/UE3.
Also I'm intrigued in Vector Displacement maps and was wondering if anybody had any good tutorials on how to create and use them.
Thanks again for the replies guys
It is pretty easy to make them in Mudbox and load them in the Maya DX11 Uber Shader.
In Mudbox you have an option to bake them in the map baking tools.
Just make sure you pick "Absolute Tangent" if you want to use the map in Maya.
Play around with things like that and see if you notice any chances... sorry i can't be more help right now.
performance is pretty good, but you should consider where and why you want to use it. additionally you may think about using similar visual techniques like parallax occlussion mapping or - for smaller details - plain old normal mapping.
he was referring to pom actually being more expensive to use than tessellation, it is mathematically more complex, and requires more shader instructions than tessellation + displacement.
so why use pom when you got tessellation which is what pom is trying to fake in hte first place.
so i would say just normals, or normals + tesselation.
POM is a great solution for things where depth matters but silhouette doesn't, such as brick walls and other things.
Don't listen to Ace-Angel's advice here, seriously, just don't.
POM is a perfectly fine solution for the example i stated above. Next gen consoles are just around the corner and this is going to be used quite a bit in next gen graphics.
Might as well just use Phong and a Color Map for all the physically accuracy it gives me room to play with at the end of the day, without breaking the entire scene.
You're wasting resources and time to make something look 'better' that won't matter at all (EI: Rocky walls) since you'll be zooming past them, or they will look absolutely terrible if focused upon (EI: Main character).
Might as well stack a bunch of rocks together in ZB and Decimate them, since at least with that I will get the silhouette AND and performance as well, artist friendly asset that will serve the purpose very well.
You might as well go with a simple Bumpoffset, and procedurally, based upon your Cavity/Normal/Displacement Map or hell, just straight out call the textures to cast the Self-Shadow effect based upon these maps from your AO with a simple Light and Camera math.
Tesselation may also be expensive, but you're not supposed to take a 500 poly character and have the Tess. Map do all the effect on it, you're supposed to use it in a clever manner, stuff like saaaay a Dragon sculpt on your character's pauldron, when getting up close will give it that 'volumetric' effect, at a reasonable count around the edges.
Different strokes for different folks I guess, but POM is really limited by extremely prepared assets beforehand, which leaves alot to be desired in the pipeline, it's simply not effective other then showing off your Shader-Skillz.
do you have any data to back this up?
again: like Ryan Smith and me pointed out: There's different usage scenarios for both situations and you should not be affraid to use and test either case.
another advantage of POM is that its pixel based effect. Imagine you have a very small pattern that you need to give some depth - if you want to use displacment, your triangulation has to be smaller/denser than the dents/lines you are trying to displace. Otherwise (less tessellation/density) you will have an uneven surface.
POM will be able to give you the effect with no problem and no change to the geometry density. Granted - this example would in most games be considered just worth a normal map. it shows the fundamental flaw though with displacement to increase detail on hard-surface objects.
From my basic understanding of it, tessellation would be better suited in bringing out the extra detail in a hero piece of a scene as the player gets closer to it, while POM is better used on things like brick walls, as it can help them pop better while not adding more geometry to a model.
I understand that tessellation/displacement maps can be used on things like flooring, but if its something a player will fly past at 100mph I'm sure it would be better suited on a big center piece model over a brick wall. I could be wrong but if anyone could let me know that would be great. Also if anyone has any data to show the cost of POM that would help me make a decision on using it in my potential scene.
cheers guys
Use tessellation if you need smoother silhouettes. Use bumpoffset if you don't (but still need to fake 3D-ness). POM shaders are really instruction heavy, so avoid using them. Most of the time you should be good with a little bit more detailed LOD0 with proper normalmaps and then less detailed LOD1 and 2.