Home Unreal Engine

UDK July 2012 now supports XNormal normals!

http://www.unrealengine.com/news/epic_games_releases_july_2012_unreal_development_kit_beta/

So unreal is now supporting xnormal normals! Yay!

I believe unreal always supported maya bakes before (I guess not now?) but it's nice finally having a universal baking method everyone can use regardless of your modeling tool if you are using unreal as your engine of choice.

Replies

  • metalliandy
    Offline / Send Message
    metalliandy interpolator
    It seems like UDK is reading the exported normals from the FBX but Epic haven't changed the tangent basis to the one that xNormal uses...at least I can't see anything that would suggest that, so I'm not sure what has changed tbh. They added the "Explicit Normals" and "Import Tangents" ages ago, didn't they?
    http://udn.epicgames.com/Three/XNormalWorkflow.html

    It would be great if someone from Epic could clarify.
  • JordanW
    Offline / Send Message
    JordanW polycounter lvl 19
    There was some changes to how explicit normals and import tangents work.
  • gsokol
    I believe unreal always supported maya bakes before (I guess not now?) but it's nice finally having a universal baking method everyone can use regardless of your modeling tool if you are using unreal as your engine of choice.

    If I read correctly, the documentation says that you can still use normal maps the way you used to (maya works fine provided you flip y), but this is the better option.
  • Ace-Angel
    Offline / Send Message
    Ace-Angel polycounter lvl 12
    • We have improved the workflow of baking and rendering normal maps
    • Notice it’s a far lower polycount than we could use before since there is no supporting chamfers or subdivisions
    • This workflow currently relies on using XNormal to bake normal maps but produces much higher quality shading than before
    • The Normal map workflow you’ve used in the past will still work, but if you want higher quality shading, this is currently the best workflow to use
    • It also allows you to use much less supporting geometry since you don’t have to fight incorrect shading
    • The first step is to make sure your model consists of 1 smoothing group
    • It also helps to triangulate your model using a modifier, that way you don’t have to worry about any application changing your triangles
    • When exporting your lowpoly model for xnormal, use these settings:
    • The important points are the smoothing groups, and tangents & binormals
    • When loading your lowpoly model into Xnormal make sure “Use exported normals” is enabled
    • After baking your normal map, export your low poly models for Unreal using the SAME FBX settings as before
    • When importing your model into Unreal, enable “Import Tangents” and “Explicit Normals”

    OK, so Xnormal is the best option, followed while you can still use Maya and Max Normals, Xnormal will essentially be the 'HD' option for shading.

    You can have 1 Smoothing Group, and triangulation is generally a good idea, and the rest is the general flow of how to do things.

    And no, Maya wasn't the standardized process for Normal Maps last I checked.

    More info here: http://udn.epicgames.com/Three/XNormalWorkflow.html

    Correct if I'm wrong, but what is the difference between FBX and the other two sporting imports for UDK? FBX is for static meshe's, right? Or does it work with Skeletal also?

    My thoughts on the update so far are this: [ame="http://www.youtube.com/watch?v=_J6-3l3hCm0"]Hell, It's about time. - YouTube[/ame]
  • Froyok
    Offline / Send Message
    Froyok greentooth
    JordanW wrote: »
    There was some changes to how explicit normals and import tangents work.

    It's only for Static mesh or Skeletal mesh are also affected ?
  • gsokol
    Correct if I'm wrong, but what is the difference between FBX and the other two sporting imports for UDK? FBX is for static meshe's, right? Or does it work with Skeletal also?

    FBX can hold a crapton of stuff. Skeletal meshes, animations, etc...
  • biofrost
    Offline / Send Message
    biofrost polycounter lvl 12
    This is great news! Can't wait to install this update.
  • tristamus
    Offline / Send Message
    tristamus polycounter lvl 9
    WOW.

    What a huge difference.

    And yes,about FUCKING time.
  • cholden
    Offline / Send Message
    cholden polycounter lvl 18
  • mospheric
    Offline / Send Message
    mospheric polycounter lvl 11
    :D Current pipeline just got better!
  • ZacD
    Offline / Send Message
    ZacD ngon master
    I just re-downloaded UDK 10 hours ago, REALLY?

    Also shouldn't this be posted in general as well?
  • metalliandy
    Offline / Send Message
    metalliandy interpolator
    W00t! This is indeed great news! Thanks for the clarification, Jordan :)
  • CordellC
    Offline / Send Message
    CordellC polycounter lvl 11
  • Computron
    Offline / Send Message
    Computron polycounter lvl 7
    So whats the deal with the one smoothing group requirement?

    Sure, it might down vertice cost, but won't it also introduce big gradients into your normal map and when coupled with comression, look possible worse in some areas?
    Can I still use smoothing splits in some areas and get the benifits of this new pipeline?
  • Xoliul
    Offline / Send Message
    Xoliul polycounter lvl 14
    JordanW wrote: »
    There was some changes to how explicit normals and import tangents work.

    OK, at work we were really confused as to what this was about, it sounded like nothing new.

    Too bad there's no change for skeletal meshes, that's where we could really use it.
  • JordanW
    Offline / Send Message
    JordanW polycounter lvl 19
    This should work for skeletal meshes as well, have you tried?
  • Money
    Offline / Send Message
    Money polycounter lvl 8
    Nice, glad to see this finally got improved. :)
  • PogoP
    Offline / Send Message
    PogoP polycounter lvl 10
    Computron wrote: »
    So whats the deal with the one smoothing group requirement?

    Sure, it might down vertice cost, but won't it also introduce big gradients into your normal map and when coupled with comression, look possible worse in some areas?
    Can I still use smoothing splits in some areas and get the benifits of this new pipeline?

    I'd like to know the answer to this question too.
  • DeadlyFreeze
    Offline / Send Message
    DeadlyFreeze polycounter lvl 17
    You can split whatever you want, it just defeats the point of having a sync'ed normals.
  • Fang
    Offline / Send Message
    Fang polycounter lvl 7
    Equivalent to Quality-mode normal maps in 3pointShader perhaps?
  • Froyok
    Offline / Send Message
    Froyok greentooth
    JordanW wrote: »
    This should work for skeletal meshes as well, have you tried?

    I have tried with one of my character, I still get some seams unfortunately.
    Does the FBX version of my file can be the problem ? I didn't re-exported my mesh in FBX, I just imported it in the new UDK.

    1343369304-normals1.jpg

    1343369299-normals2.jpg

    (By reimpoted I mean a true new import, not the right-click reimport in the content browser)
  • Quack!
    Offline / Send Message
    Quack! polycounter lvl 17
    You MUST use fbx with the settings they showed. The old actor x exporter won't work.
  • Froyok
    Offline / Send Message
    Froyok greentooth
    I always use FBX files and the settings they ask since the beginning (even before this update).
  • CT007
    Offline / Send Message
    CT007 polycounter lvl 13
    Check it out, it WORKS! :D (not sure if those black seams are my bad or not...lol)
    nice.PNG
  • Computron
    Offline / Send Message
    Computron polycounter lvl 7
    You can split whatever you want, it just defeats the point of having a sync'ed normals.

    Nope, you are mistaken.

    Here is Earthquakes post from another July UDK thread:

    EarthQuake wrote: »
    I just want to touch on this quickly. In general terms this is bad advice. Even with a perfectly synced workflow, you still want to split your edges/SGs at your UV borders. Because:
    1. Its free, there is no extra vertex cost.
    2. Your normal maps will have less artifacts, even with 100% synced workflow
    3. Your normal maps will generally compress better(less crazy gradients etc)
    4. Reuse may be easier in some instances.
    5. A script can do this for you in 1 second in Max/Maya.

    And there are literally no cons. The only possible con is if you've got a weird baking workflow where your cage is not averaged(ie: offset method in max, not using a proper cage in Xnormal) than your projection mesh gives you a gap at your hard edges, but nobody should be baking like this.

    TL;DR: "Using one smoothing group" isn't the point of a synced workflow, it is easier to do with a synced workflow, but it isn't the end goal.
  • TA20
    good result!:thumbup: It is a perfect flat field.
    236-1.jpg

    We need to use lowpoly by fbx when bake with xNormal.
  • TychoVII
    Offline / Send Message
    TychoVII polycounter lvl 13
    I seem to be having an issue with my mirrored pieces. The green channel seems to be flipped for those pieces. Not sure how to fix it if they share the same UV space. This model uses 'all 1 smoothing group' as Epic suggests.

    j519G.jpg


    And for some reason I'm getting faceting on this piece.

    9AOFA.jpg

    Anybody have any ideas?
  • Quack!
    Offline / Send Message
    Quack! polycounter lvl 17
    Move your duplicate overlapped uvs out of the 0,1 space for you first image.
  • TychoVII
    Offline / Send Message
    TychoVII polycounter lvl 13
    Quack! wrote: »
    Move your duplicate overlapped uvs out of the 0,1 space for you first image.

    I did exactly that. Tried it both before and after baking, but nothing seems to change.

    dfEXq.jpg
  • McGreed
    Offline / Send Message
    McGreed polycounter lvl 15
    Oh I remember something about this, I think it might be because your unwrap isn't horizontal, so the mirrored version will get the wrong informations. Try look up mirror normals, apparently there is something about only mirror horizontal, and not vertical. I might be blowing smoke out of my cloak, but maybe just do a quick test?

    Also, check that your second channel for the lightmap has been unwrap properly and unique, no overlapping or outside the 0,0 space.

    Another thing you should try, is to delete the mirrored part, and then use Symmentry to recreate it, this will mirror both mesh and UV, and then move the uvisland outside the 0,0 area.

    And with my third edit of the post (lol), here is an thread that might help as well: http://www.polycount.com/forum/showthread.php?t=76636 They talk about the mirror issues well.
  • TychoVII
    Offline / Send Message
    TychoVII polycounter lvl 13
    Thankyou much McGreed! I will investigate these options thoroughly and come back with results.

    EDIT:
    After reading through that thread I realized that that problem only seems to affect people with lightmap issues. I'm not using any lightmaps at the moment and for thsi model they're not really necessary. Using a symmetry modifier was how I originally duplicated those pieces. I also tried cloning and mirroring, to no avail. I think I'm going to create a new thread and see if I can get some more eyes on the issue because I'm running out of ideas. Thanks for the suggestions man!
  • danRod
    Offline / Send Message
    danRod polycounter lvl 18
    hey guys I am following the udk forums on how to use xnormals for unreal and when I have mirrored geometry the normals are all flipped. Any word on this? I offset the mirrored uvs to the right 1 unit int he uv editor and when it comes into unreal it is all flipped. seams like just the red is f;lipped but the green read right for the mirrored uvs.
  • Froyok
    Offline / Send Message
    Froyok greentooth
    danRod wrote: »
    hey guys I am following the udk forums on how to use xnormals for unreal and when I have mirrored geometry the normals are all flipped. Any word on this? I offset the mirrored uvs to the right 1 unit int he uv editor and when it comes into unreal it is all flipped. seams like just the red is f;lipped but the green read right for the mirrored uvs.
    I have a friend which got the same problem on a skeletal mesh. The only workaround that I have found to solves his problem was to use vertex color to identity the flipped geometry and use it as a mask in the material to flip backward the green channel :

    1348862836-em_material.jpg
  • JamesWild
    Offline / Send Message
    JamesWild polycounter lvl 8
    I've never had that problem but there's got to be a better workaround than that. The problem is that one of the tangents is pointing the wrong way. Not used Max in a good while but is there no way to edit tangents in it?

    On implementation, some performance could be saved by removing the desaturation and linking directly to one of the vertex colour channels (red/green/blue/alpha) freeing up the others. The power shouldn't be necessary on floating geometry.
Sign In or Register to comment.