Why does UDK suck so bad at NMs
Why?! In 3 pointshader it always displays mirrored normals, flipped, rotated UV clusters anyway I please:: Correctly. It seems like this is how game engines should be! Just do it like you normally would and not have to go through a million "tricks" to try and get it to show up magically correct in udk.
I know u'll say its because the tangent basis of the baker and udk not matching up. Well damn I guess NOTHING matches up with udk.. because no matter what I bake in it will always have some sort of issue with the NM, ALWays,
This is 2012 not 1920s lol, why doesnt udks normal map display be as good as a real time viewer like 3 point, or Xoliul?
I know u'll say its because the tangent basis of the baker and udk not matching up. Well damn I guess NOTHING matches up with udk.. because no matter what I bake in it will always have some sort of issue with the NM, ALWays,
This is 2012 not 1920s lol, why doesnt udks normal map display be as good as a real time viewer like 3 point, or Xoliul?
Replies
because at least 3point (not sure about xoliul) is synched with max, simple as that, maps baked from maya won't look anywhere near as perfect was with 3p in max, or max maps in maya.
did you try exporting the tangents via fbx and let unreal import those? i haven't tested in a while but at least from maya this worked for me last time i tried.
Yeah if you're exporting from Max, this is entirely the way to go. Epic is phasing out use of ASE in UDK, so using FBX and it's explicit normals/custom binormals is really kinda required to get it as close as possible to the Max mesh.
i would love to say that this works with unity, so far i couldn't get correct tangents to show up there from max and as the whole production right now is max centric going via maya is also no viable option
I wrote a quick guide for this here:
http://www.3dmotive.com/exportingqualifiednormals/
The rest of the model is great, it's just these Elements that are faceted when the normal map is turned on, their UV cluster rotation seems to have nothing to do with it. The issue is NOT present in 3point or Xoliul. It seems to be splitting the UVs.. but I am SURE that I have them weilded down before export. I am exporting it already triangulated in Max, (once again looks great in 3 point) I checked the uvs after I triangulated.. and no splits, I exported with FBX, tangents and binormals, AND smoothing groups checked.. I imported into UDK with import tangents AND remove degenerates checked... It is lit dynamically, there should be NO baked lighting issues. I checked elements for flipped normals.. they are NOT flipped. I reset Xforms. I imported as TCNormal map, I flipped channels. No avail. I also tried importing every way possible with fbx. faceting is gone IF I let udk triangulate it for me, but THEN the normal map looks horrid.
And we would all live happily ever after, but noooo...
haha... would be nice to have a synched up bake solution now wouldn't it?
It would
I asked them several times in their forums and even sent then email saying how I will kill a Cookie Kitten for every day they delay it and why on Earth would they hamper their own stuff.
So far I killed over 600 Cookie Kittens, your move Epic...
Right, I dont think its a problem of "Epic is holding out on us". I think that the issue is that they aren't really aware of the problem or maybe more specifically do not *agree* that it is a problem. I've seen Epic artists claim on here that "UDK is synced with max"(to be fair this was a couple years ago) which is incorrect, it turns out Epic's artists are just doing the same hacks as everyone else when getting NMs into UDK.
Its odd though, with so many Polycounters at Epic you would assume someone would have noticed by now, so maybe it is more of a technical issue.
I converted it to patch then to mesh in max, I checked the uvs after and weilded them down. If I let fbx or udk triangulate it, the normal map gets harsh seems on all smoothing group edges and looks alot worse.
Also, many of the issues people run into are compounded by the fact that Unreal uses directional lightmapping. From what I've read, UDK calculates a tangent basis for lighting based on the UV's for channel 0 so that it can give some directionality to specular highlights. This complicates things when you want to mirror and tile materials with normal maps.
I for one hope the next generation of hardware kills the need for tangent based normal maps. They've served their purpose and have helped us make amazing looking content, but fighting the process and tools, bouncing between multiple apps and dealing with pipelines has sucked the fun out of creating assets. Ever since I've read this whitepaper I've been drooling and crossing my fingers this becomes the next "thing" for artists:
http://jbit.net/~sparky/sfgrad_bump/mm_sfgrad_bump.pdf
Epic actually recommends that you use TC_NormalMapUncompressed for normals over TC_NormalMap. If none of the standard hacks fix the issue (enough geo, uv islands all correct, smoothing groups correct, etc) Then this may be your last hope. You do lose resolution from your NM but it isn't as drastic as it sounds. Try it out.
Do you have a copy from before this conversion? It is safer to select all your verts and hit connect. Converting your geometry to patch may break things in unexpected ways.
Also, make sure you don't have other UV channels with splits in them.
Also, if what EQ said is right, I'm sorely disappointed at the peeps from Epic.
Here is why;
Lets say for the sake of argument that Epic has 50 artist working on a game. These 50 artists need to do 'something' to get the baking correct, lets say this process takes about 10-15 minutes.
For a total of 50 artists, you're wasting between 300-500 man hours for one piece from each artist in TOTAL, if each artists does more then 1 piece, that adds up, and I'm not even talking about revisions where certain pieces might look 'old' and need a revamp or something about 6 months down the line.
This is beyond being 'silly', this is lazy, a waste of time and man-hour all in one. Normal Maps are already though to bake, why complicate your pipeline more? Doesn't Epic want to make the most out of their time and talent, instead of doing kludge work?
And just how lazy are the artists? I would force my artists to visit polycount as often as possible and learn about polygon/texture technicalities before they do anything in those regards.
Ditto for Crytek, since they aren't even synced to their own baker according to EarthQuake.
AFAIK this problem is currently being looked at internally, as soon as we get it, and it's tested properly, the plugin will be released along with the FreeSDK.
So far, Crytek's art teams have been struggling with the same problems as anyone else. Hopefully this pain will stop, for everyone using CE3, and we'll have no more Tangent Space shading discrepancies between the baker and the ingame renderer.
I tried now the connect, result is the same. It only has 1 uv channel for sure, I checked after import. I looked around other areas of the mesh in udk up close, and some other curved surfaces are also having the same faceting. I tried adding that quality normal line to my 3dxmax.ini file.. no change ;/ mesh verts are all welded up as well.
I can tell that its importing quality normals, because it looks much better when theyre imported. BUT it only works if I triangulate it before export from max myself. Faceting. The normalmapuncompressed just makes me see the faceting clearer
Sync it to Max, you guys are already using Max's UI.
If this happens, I'm moving my whole project to CE3!
The elements that were faceted I detached into seperate objects, played with their triangulation, left them as editable polys, and exported with fbx tangents and smoothing groups checked. Before export it gave me a warning about turned edges on the affected objects, which was good cause I noticed that If i didnt get that warning about the objects the faceting would appear again in udk. I suspect that if you get the warning for turned edges, it wont use imported tangents on them objects. Then I imported it into udk with combine meshes checked.
For a game engine export? Yeah, it should be fine.
For baking? Not so sure, since I always get a striated edge in my bake vs. Quads which give me clean bakes.
But then again, I use xNormal, so there is that!
Nope, I tried that 3 times (from Max) and a triangulated mesh will give me striations in my Normal bake 100% of the time.
Since I'm not too sure about the exact details, the long story comes down to: there is no way to sync correctly, due to the way the engine works internally (hence why Epic themselves can't do much).
It loses accuracy somewhere down the render pipeline, and there is no way for normalmaps to correct that. We should just hope UE4 is better and stick with proven methods like beveling edges more.
I have not tested this scientifically, but in practice it doesn't seem to matter if you triangulate before you bake if you are doing it within the same program. So if you are using max I don't think that you need to triangulate before you bake in max, I turn to poly after the bake, and my maps turn out as I would expect.
If you are baking in an external program I would always triangulate before exporting and baking.
you mean just inside the actual texture or in the final result rendered in realtime?
if you export out as sbm for xnormal it cut's it to tris by it's self anyways.
i've never really had problems with triangulation, baking and the game engine before mostly just get issues with turned edges, when exporting fbx from max to maya.
especially with maya in mind with no possibility to change the internal triangulation, or did i miss something there? as i see it, it is using the shortest way between verts to determine how to triangulate internally, right?
I realize this isn't helpful for normal maps and tangent data, as you really want your triangulation to remain the same throughout the process to avoid those "cross" type smoothing errors, but just in the cases where non-planar triangulation is going to make a visual difference on you model.
However, using SBM doesn't give me that issue, and baking inside Max also doesn't give me that issue.
No idea why, and don't plan on spending time on finding out why (since let's face it, not many people will care about this point).
d'oh. is part of the problem their uv channel 0 lookups for specular lightmap calculation? so annoying.
Wait, hold on, I thought if you used the old broken baker from Max (2008, 2009, etc) you could get the correct tangents for UDK to render properly?
Unless I'm mistaken from what I read around the net, that sounds like an issue where no one wants to use that 'broken' math anymore and simply doesn't want to implement it in it's own bakers, which is kinda like saying "Oh, we have an old 'broken' solution for a 'broken' issue, but won't implement to fix the issue because we only like clean, working stuff".
See the paradox?