UDK July 2012 now supports XNormal normals!

Thor Sowards

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.

metalliandy

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

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

• 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

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

This is great news! Can't wait to install this update.

tristamus

WOW.

What a huge difference.

And yes,about FUCKING time.

cholden

yay new toys

mospheric

Current pipeline just got better!

ZacD

I just re-downloaded UDK 10 hours ago, REALLY?

Also shouldn't this be posted in general as well?

metalliandy

W00t! This is indeed great news! Thanks for the clarification, Jordan

CordellC

About time!

Computron

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

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

This should work for skeletal meshes as well, have you tried?

Money

Nice, glad to see this finally got improved.

PogoP

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

You can split whatever you want, it just defeats the point of having a sync'ed normals.

Fang

Equivalent to Quality-mode normal maps in 3pointShader perhaps?

Froyok

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.





(By reimpoted I mean a true new import, not the right-click reimport in the content browser)

Quack!

You MUST use fbx with the settings they showed. The old actor x exporter won't work.

Froyok

I always use FBX files and the settings they ask since the beginning (even before this update).

CT007

Check it out, it WORKS! (not sure if those black seams are my bad or not...lol)

Computron

DeadlyFreeze wrote: »

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.


We need to use lowpoly by fbx when bake with xNormal.

TychoVII

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.




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



Anybody have any ideas?

Quack!

Move your duplicate overlapped uvs out of the 0,1 space for you first image.

TychoVII

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.

McGreed

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

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

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

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 :

JamesWild

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.