Isn't it more of a case of being closer to Max,, but still not right. I mean using a max normal map in UDK doesn't result in anywhere near the quality that you would get rendering it with 3Point, or 'Qualified' normals.
Unless its been updated since last I used it, which admittedly is about a year.
I think that has to do mostly with the compression. Taking a wild stab in the dark, unreal can't devote as much raw power to displaying normal maps in real time like a quality viewport shader can? It has to balance so much more and on such a grand scale.
Unreal also layers on post processing effects which could account for some quality drops or sharpness decreases. Smear Vaseline on your monitor (bloom) and lens flares, crank up the Chromatic aberration and wonder where your normal map went? heh. Couple that with heavy compression and you get something looking worse?
That's all just conjecture and speculation so I could be way off.
Autodesk products are "upstream" in the game asset pipeline.
They also deal with a lot of complexity (viewport and renderer technologies - some of which are not our own (plugins))
What we are seeing is that these products are converging in suites that are tightly integrated.
We will provide documentation on how things work in these products so algorithms may be replicated externally in any game engine (middleware or proprietary). In fact, the normal map white paper reveals shader code we used internally
I'm hopeful we will be able to support other "3rd party" tangent basis as well as with any standards, they are reasons to not use them
Yeah, it's simpler than that, they're just using the broken tangent space.
I've shot down this rumor repeatedly, but just to further cement it: We're not doing any processing intensive or resource intensive stuff to render Quality Mode normals. Performance is not a problem.
Well thats good to hear, its not the first time Epic sort of dropped the ball on normal maps... It was an uphill battle to get seams along mirrored geometry working correctly in unreal until they flipped a few switches and make a few recalculations after much saber rattling and... b!tching =/
I've been playing with UDK lately, and from my tests it is compatible with Maya bakes and xNormal (Morten's standard) bakes as long as you export/import the model with explicit tangents.
All I can say is every time we have to do assets for unreal engine (and a LOT of companies use it) our guys get all depressed about it, because not only do the models end up with twice as many polygons, but even then the shading is still bad.
Amen. Or you refuse to use support geo and get seams wherever you have UV splits... it's completely retarded.
Are you saying you've had problems doing the same with 3ds Max qualified mode exports to UDK?
Why, is that supposed to work? If the problem is UDK-side I don't see how you export things matter, but if there's anything that can be done to help the situation I'd be very interested to hear it.
Good stuff Per, thanks. Now all we need is a benevolent programmer to share an edited version of the FBX exporter and anybody with a copy of the 3point shader should be able to get flawless normals in UDK, if I follow you correctly.
Perna: I haven't run any tests with max's RTT lately. Is the 2012 FBX exporting qualified tangents in qualified mode now? That would be some great news. Could the artifacts from Nitruos appear because of some triangulation issues?
I wonder what an xNormal bake would look like on a LP mesh with qualified tangents.
The problem is simply that UDK generates the wrong tangent data.
With FBX you can export that data with the model.
For nearly a year you've been able to import that data into UDK.
The problem is 3ds Max used to provide wrong tangent data.
3ds Max 2012 in "qualified mode" provides the correct data.
3Point Shader ALSO provides that data for all version of max since 2008. However, since it can't directly modify the tangent data in max, it adds it in extra vertex channels. In order to successfully export this data you need a custom FBX exporter. The FBX source code is out there so it may or may not be more practical for each company to get a programmer to write a very small edit to the exporter than to aquire 3ds Max 2012 for everybody.
Does that mean all is good? No, only improved. You're still not getting full quality.
There are visual artifacts in the qualified mode UDK shots too.
We see those exact same artifacts with 3ds Max 20120 Nitrous qualified mode, but NOT in D3D qualified mode, so there's still work to be done:
Lastly, UDK should include a mode to recalc the missing tangent data, because the FBX tangent support requires you to re-export every single asset all over again. We've tested such recalc code with very good results. Not as good as native export, but a significant improvement.
Please note there seems to be technical problems with qualified mode for some people. If this happens to you and you want to see the "ultimate" output quality you can get from 3ds Max normals, use 3Point Shader Lite (it's free) with the 3Point Quality Mode modifier. If what you're getting in the viewport/UDK/whatever isn't identical (keep in mind that 3Point Shader does its own gamma correction), something is wrong.
Just to follow up with this qualified normals -> FBX -> Unreal Pipeline -
These are the results I have been able to get so far. I could be doing something wrong.
The object is a 1 smoothing group cube with stitched UVs. I'm exporting from 3dsmax 2012 with working qualified normals (cube looks perfect in dx viewport). In my FBX options I have "Tangents and Binormals" checked and in Unreal I have "Explicit Normals" checked.
I could be doing something wrong, there is certainly an improvement but its probably not large enough to start stitching UVs for 90 degree corners and smoothing them (thereby reducing vert counts). Still, it seems like this will be really useful for curvilinear hard surface type work. In practice things will shade better and at times require less geo.
Here is a more practical testing scenario. MP7 provided by racer_445
if its all 1 smoothing group, then doesnt that cause issues with the breaks in your UVs? if you have your UVs split along an edge shouldnt the smoothing groups be separated along the respective edge?
Oniram : thats the opposite. If you SG, then you split UVs where you SG. But If you split UVs, you don't necessarily have to SG at these splits, at all. Try it - it's very obvious once you see the resulting maps.
As you can see no luck. I dont know why the devs arent more keen to solve such a serious issue. Fortunately the engine where I work solved this issue years ago but it sure would be nice to have a decent way to display normals for my home pet projects too.
You can (and in most cases should) have smoothing breaks on areas where you have UV splits. It's free and your normal map won't have to work as hard. The exception to this would be splits across a smooth curved area (like a group of faces on a sphere).
For a perfect workflow like qualified normals or 3points shader its not going to matter much if you use 1 smoothing group or add these splits. But even in these circumstances you can get some small shading errors when you have tight triangulation. Essentially there isn't always enough pixel precision in the normal map to properly compensate for intense triangulation.
When possible, let flat areas bake out to be 128,128,255 and not a gradient.
You can (and in most cases should) have smoothing breaks on areas where you have UV splits. It's free and your normal map won't have to work as hard. The exception to this would be splits across a smooth curved area (like a group of faces on a sphere).
For a perfect workflow like qualified normals or 3points shader its not going to matter much if you use 1 smoothing group or add these splits. But even in these circumstances you can get some small shading errors when you have tight triangulation. Essentially there isn't always enough pixel precision in the normal map to properly compensate for intense triangulation.
When possible, let flat areas bake out to be 128,128,255 and not a gradient.
ok that helps. now question, could you (or anyone here) explain what qualified normals is? ive been digging through old threads and saw it was something that needed to be changed in your .ini when hotfix 4 came out for 2011, but how does this work in 2012, and how is it different from 3ps quality normals (if there are any differences).
Alec: Yeah, that really blows, I found out the same recently. I'd be really interested to see if you or anyone else have examples of Static Meshes still having seams at edges of UV islands (ie, achieving what copenhagenjazz does with his leftmost cube above). Fixing that would be a huge step forward even if general smoothing still isn't 100% perfect as per your MP7 example, Alec. Completely agree with your workflow/flat areas btw.
I'm lost in all this infos :poly122:
My question is ,there is a tutorial/videotutorial that shows the most up to date workflow to get the better normal possible (for now)? (I'm using 3ds max)
A lot has changed in 3dsmax how it displays normal maps, in part due to this thread probably... But basically the workflow is the same just how you display normal maps is a bit different. Viewing it in engine will be the best indication of how it will look in game, obviously but since that is often slow and convoluted you will want to test out the various methods of viewport display depending on what version of max you're using. Xhoulioio shader, 3point shader, standard max viewport set to realistic. Or bake and display in xNormal. There are a lot of choices and you just need to find one that works best for you and your project.
There really isn't one solid way because engines can use different settings to display normal maps in different ways. So you need to find a method that displays ABC results in a reliable way.
No... It was a lot worse and now its fixed in max. Before there wasn't a way to display normal maps in the viewport without using 3rd party software. Now max displays them just fine without 3rd party software.
However, because there are many ways to render and use normal maps within all of the various engines and there isn't one standard way, you need to make sure your display method is sync'ed to your engine.
So you will want to make sure that what you see in the max viewport matches what you see in whatever engine you're using before devoting a lot of time to baking and doing materials in max.
Replies
Unreal also layers on post processing effects which could account for some quality drops or sharpness decreases. Smear Vaseline on your monitor (bloom) and lens flares, crank up the Chromatic aberration and wonder where your normal map went? heh. Couple that with heavy compression and you get something looking worse?
That's all just conjecture and speculation so I could be way off.
They also deal with a lot of complexity (viewport and renderer technologies - some of which are not our own (plugins))
What we are seeing is that these products are converging in suites that are tightly integrated.
We will provide documentation on how things work in these products so algorithms may be replicated externally in any game engine (middleware or proprietary). In fact, the normal map white paper reveals shader code we used internally
I'm hopeful we will be able to support other "3rd party" tangent basis as well as with any standards, they are reasons to not use them
Amen. Or you refuse to use support geo and get seams wherever you have UV splits... it's completely retarded.
Why, is that supposed to work? If the problem is UDK-side I don't see how you export things matter, but if there's anything that can be done to help the situation I'd be very interested to hear it.
I wonder what an xNormal bake would look like on a LP mesh with qualified tangents.
Just to follow up with this qualified normals -> FBX -> Unreal Pipeline -
These are the results I have been able to get so far. I could be doing something wrong.
The object is a 1 smoothing group cube with stitched UVs. I'm exporting from 3dsmax 2012 with working qualified normals (cube looks perfect in dx viewport). In my FBX options I have "Tangents and Binormals" checked and in Unreal I have "Explicit Normals" checked.
I could be doing something wrong, there is certainly an improvement but its probably not large enough to start stitching UVs for 90 degree corners and smoothing them (thereby reducing vert counts). Still, it seems like this will be really useful for curvilinear hard surface type work. In practice things will shade better and at times require less geo.
Here is a more practical testing scenario. MP7 provided by racer_445
if its all 1 smoothing group, then doesnt that cause issues with the breaks in your UVs? if you have your UVs split along an edge shouldnt the smoothing groups be separated along the respective edge?
Linkt to thread; http://forum.unity3d.com/threads/38781-Calculating-Unity-s-tangent-basis-for-xNormal
As you can see no luck. I dont know why the devs arent more keen to solve such a serious issue. Fortunately the engine where I work solved this issue years ago but it sure would be nice to have a decent way to display normals for my home pet projects too.
You can (and in most cases should) have smoothing breaks on areas where you have UV splits. It's free and your normal map won't have to work as hard. The exception to this would be splits across a smooth curved area (like a group of faces on a sphere).
For a perfect workflow like qualified normals or 3points shader its not going to matter much if you use 1 smoothing group or add these splits. But even in these circumstances you can get some small shading errors when you have tight triangulation. Essentially there isn't always enough pixel precision in the normal map to properly compensate for intense triangulation.
When possible, let flat areas bake out to be 128,128,255 and not a gradient.
In my small experience i've found its benificial to avoid getting un wanted shadowing on baked bevels facing away from the camera
ok that helps. now question, could you (or anyone here) explain what qualified normals is? ive been digging through old threads and saw it was something that needed to be changed in your .ini when hotfix 4 came out for 2011, but how does this work in 2012, and how is it different from 3ps quality normals (if there are any differences).
[ViewportNormalMapping]
ViewportNormalMappingType=Qualified
to you 3dsmax.ini which is found at "\Users\UserName\AppData\Local\Autodesk\3dsmax\3dsmax 2011 or 2012\enu"
If you are on 2012 you also must be running the viewport in DirectX mode since nitrous still only renders with the old behavior.
My question is ,there is a tutorial/videotutorial that shows the most up to date workflow to get the better normal possible (for now)? (I'm using 3ds max)
There really isn't one solid way because engines can use different settings to display normal maps in different ways. So you need to find a method that displays ABC results in a reliable way.
However, because there are many ways to render and use normal maps within all of the various engines and there isn't one standard way, you need to make sure your display method is sync'ed to your engine.
So you will want to make sure that what you see in the max viewport matches what you see in whatever engine you're using before devoting a lot of time to baking and doing materials in max.
There is something like it aroud?
http://www.polycount.com/forum/showthread.php?t=108744