Question about normals, UVs and smoothing groups
polycounter lvl 13
Okay, so I'm aware that splitting your UVs by smoothing groups will result in a higher quality normal map. One thing that gets me though is how you go about this for objects that might have numerous 90 degree edges with narrow polys. If I were split each edge in the UV then I'd get a better normal map - but this would really fiddly to texture.
So in this situation is it best to give all these polys a single smoothing group - giving funky smoothing in the viewport - keep the UVs attached and bake out a normal from that? Presumably that's fine because the normal map would just fix the funky smoothing?
Is this something that's done often for assets when splitting the UVs isn't ideal for texturing?
So in this situation is it best to give all these polys a single smoothing group - giving funky smoothing in the viewport - keep the UVs attached and bake out a normal from that? Presumably that's fine because the normal map would just fix the funky smoothing?
Is this something that's done often for assets when splitting the UVs isn't ideal for texturing?
Replies
The ideal case is always keeping the model in 1 smoothing group, but due to triangle count limitations most of time that`s impossible, so, divide you model in smoothing groups so you don`t get strong shading errors, divide your uvs accordingly, and never put 2 triangles with different smoothing groups sharing the same uv island.
Obviously you should be thinking about your UVs when doing your lo-poly for situations like this. Is it going to make a difference in your silhouette if you simply make those faces 80 degrees and apply one smoothing group to the group in question?
That's the only thing I can think of if you don't wish to split your UVs on the hard edges.
Why not? If you are not using a synced renderer, then your normal maps will display better if they are more flat or closer to 128,128,255 in color.
So to get a nice edge on this here, I'd have different smoothing groups and split the UVs, but then it just becomes a bit of a pain to texture with the seams. So the upside of just not baking and leaving the edges sharp is that I could texture it easier.
Not true if your baker and renderer are synced.
Right, with this sort of mesh you'll have a lot of seams. One thing you can do is actually alter your design to simplify the lowpoly shapes, and put more of the detail into the high etc.
Depending on scale/geometry budget you can bevel some of these edges so you don't need to rely on hard edges and use less seams as well.
Wesley: if texturing seams are your concern use mudbox, bodypaint or any other program that allows you to paint directly on the model, seams are not a problem that way.
3ds max and the 3 point shader.
Also mudbox doesn't magically fix normal map seams.
This is how I would model that 90 degree part, low and high.
I was not talking about normal maps, he said texturing so i assumed he refered to difusse, specular and other kind of map regarding painting textures.
Max + 3point Shader
Maya + Maya viewport
Maya + Splash Damage's engine for Brink.
Doom3 + Renderbump
+ A few other projects I've worked on but can't mention due to NDA.
:O i see, Cry engine has its own baker too, and may be UDK and qualified normals form max? In the end we must learn to get good normal maps even if baker and renderer are not synced, some of those examples are for modeling packages and not game engines, so in most cases, baking 90 angle degree triangles with the same smoothing group will result in an ugly mess
Crytek is humorously not synced with its own proprietary baker. The max qualified normal trick is great but not 100% accurate, and only works with static meshes unfortunately.
Of course you should know how to bake maps with broken workflows, I totally agree with you.
HOWEVER, telling people "never do this" "because thats the way it is" when its simply incorrect is a really huge part of the problem. Most artists just assume they need to work with these broken systems, because someone else at some point told them "thats how normal maps work" and it is completely incorrect. The less people understand the issue, the less people complain to thier tech artists, graphics programers etc and demand synced normals the more we all have to deal with these horribly slow, inefficient and simply broken workflows.
Trust me, once you've worked on multiple assets in a synced pipeline you will BEG the technical guys on any/every project you work on to get synced normals. Its so much easier and straight forward for the artist, it isn't more expensive on the shader side, and it saves a lot of verts/triangles because you don't need as many hard edges or supporting bevels to solve smoothing issues. Better/easier/faster for everyone, except the programmer who has to spend 1-2 day implementing it. =P
PS: Whats the difference between a realtime shader in a 3d app and a realtime shader in a game engine?
You gotta be joking. Although it makes a lot of sense given, crytek.
I wish I was, Racer445 did some extensive testing a while back, as most people simply assumed it was synced(otherwise why bother with a custom app lolol).
I'm pretty confused by this response. Leaving hard edges welded? What does that even mean? Are you actually breaking the verts where you have hard edges? This will cause some pretty bad issues if you are.
Even with an unsynced workflow using hard edges is not your only option. You can bevel the edges of your hard angles and often come out to about the same vertex count for instance. I will generally do a bit of both when dealing with broken workflows.
With complex, hard surface models that have lots of hard angles, excessive use of hard edges/smoothing groups can create really really bad uv layouts that are hard to work with, and really really inefficient vertex counts(your uv vert count is generally your "real" or "ingame" vert count).
Not only beveling hard edges, but adding in extra geometry to soften your normals, as well as good planing/designing/alterting concepts in a way that will translate to less hard angles in your lowpoly is a really great way to avoid problems too. Using sloped shapes instead of stepped shapes can really help like this: http://www.polycount.com/forum/showpost.php?p=1288654&postcount=9 This was an example on how to minimize waviness artifacts, but since you're softening the normals when you work like this, it also helps a great deal for broken tangents.
Also, about syncing the process: I'm baking in xNormal (X+ Y- Z+) and am using CryEngine; which is synced? I'm confused on what constitutes as synced. But if xNormal>CryEngine were synced would that mean I could keep UVs stitched and let the baking do its job?
My project is for uni so all of this is super-useful and will be going into my documentation.
There are two issues here:
A. Swizzle/Handedness: this is your XYZ orientation and doesn't have anything to do with the baker being synced or not, every engine simply does it one way or the other; -Y or +Y.
B. Being synced refers to having your normals/binormals/tangents/(otherwise known as tangent bias) perfectly synced between baker and renderer(app or game engine). As an artist there isn't really anything you can do to force this, its just how your tools work together. Some combinations as listed above are synced, the rest you can generally assume are not.
When your tangent bias is not synced you will get smoothing errors. Your smoothing errors will be worse the more extreme your shading/angle changes are in your mesh normals. So you can use hard edges, extra geometry, bevels, or plan/simplify your low frequency shapes to reduce the complexity of you lowpoly model or add slopes instead of hard angles.
ZacD's post earlier in the thread was a good example of:
A. Simplifying your design/low, and
B. Using some extra geometry to soften angles
This sort of thinking really helps to avoid excessive hard edges/smoothing groups, and in turn excessive uv splits/islands which are a pain to texture.
http://freesdk.crydev.net/display/COMMUNITY/xNormal+Plugin
An Xnormal CryEngine tangent basis plugin was actually released a while back, except the problem is that it most likely uses the same calculations as whatever polybump does so it doesn't actually sync up.
The difference of a shader in a 3D app and a game engine is that you are not going to make a game within a 3D app, you can bake some awsome normal maps in maya o or use the 3 point shader in max, go with your friends and tell them how cool they look, now take your maps to udk or another unsynced engine and there just ends the coolness of your synced bake XD
And yes, it was wrong to just say "never do this" if you can ask a tech artist or a programmer to do it in a couple of days, we absolutelly agree that scynced methods are the best way to go, but if that`s not at your disposal, yeah absolutely NEVER DO IT.
About cryngine i read about it, never tryed it myself, jus note that it was not an affirmation, just a question to reinforce your argument, but it ended up being another reason to learn how to do things an a "broken way" if you need it.
It's a spambot that's quoting a snippet of my reply near the top of this thread.
Edit:
Never mind- I thought it had read key words out of a different post and managed to put it together into a coherent statement.
Relevant XKCD http://xkcd.com/810/
I'm not sure if there is an organized resource for it anywhere, but you might want to check out this thread: http://www.polycount.com/forum/showthread.php?t=68173
Theres some links in that thread to official autodesk stuff as well^^^
wiki: http://wiki.polycount.com/NormalMap?action=show&redirect=Normal+Map#Tangent_Basis
When applying different smoothing groups the angle is what's affected in the process and not the faces though the face is what you apply the smoothing groups to. Any series of connected faces that share the same plane should always share the same smoothing group to prevent unwanted hard edges. Hard edges simply are where the different smoothing groups meet. If there's a hard edge that means that the Vertex Normals are split, but if they share the same smoothing group it's as if the Vertex Normals are bending into each other. Establishing that, if you want to eliminate a hard edge apply 1 smoothing group or if necessary use a common smoothing group between 2 already differentiating groups.
More then one smoothing group saves triangles, but then you need to have UV seams wherever there is a hard edge. This adds to the seam count because you'll also have other places where a seam occurs that doesn't have anything to do with the smoothing groups. You could place a seam on the hard edge so they occupy the same UV space in order to limit seam separation. There are many avenues to go down depending on whether or not you want more seams but less geometry or less seams but more geometry. Adding a little more geometry instead of smoothing groups boosts the triangle count, but creates less seams. Unwrapping the model into varying UVs as well as having random hard edges will produce an ugly Normal Map with artifacts. l Am I right in that texturing takes up more memory then geometry so adding a few more polygons to the picture wouldn't be as severe as adding wasted textures?
So if everything I know so far is correct, what is usually the best course of action? I'd imagine most of the time you wouldn't want just 1 smoothing group unless you're working on an organic object like a rock which only leaves the option of having multiple smoothing groups. If you're locked into splitting the UVs where the hard edges are, this means your texturing is going to be off. The way the model is unwrapped would combine different elements resulting in having to be more careful where you lay out materials in PhotoShop. Up until now I've found it easier to texture when dividing the model by its elements even at the cost of a few extra seams, but that might be all for not if I do indeed have to follow these rules with smoothing groups. I feel like the more answers I arrive at the more questions I need answered haha. Any guidance would be much appreciated.