Home Adobe Substance

Trying to bake very seemingly simple Normals in SP2, weird notches and lines on edges appearing??

polycounter lvl 5
Offline / Send Message
PJPayne polycounter lvl 5
Hey I was wondering if I could get some help with a Normals Issue:

1- the final baking with a couple notches in it for what I can tell to be no reason
2- the Low poly
3- High poly

Anyone have any suggestions to fix this? I am baking in Substance Painter 2. Online forums didn't help though they did help with getting one problem away but this has persisted.

Replies

  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    Could be plenty of things, mind uploading your bake mesh + high res mesh? :smile:
  • PJPayne
  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    Well, immediately noticed that your high res model is extremely sharp, i'd recommend thickening up that bevel/chamfer on its edges. (I've adjusted it and included it in the link below with the fixes)



    Your low-res mesh didn't have smoothing/hard edges, maybe it broke on export, but I did that anyway for it. Because of it's hard edges, we now want to split those hard edges in the UV's. That'll most likely be the culprit of those black edges, however they look a bit different than typical bake errors from that reason anyway.

    Bakes out perfectly fine after those couple of adjustments to the low/high res meshes :smile:



    https://drive.google.com/open?id=1WGemn8SPvNpohHrMRvplOd5QJ6cHpOyH
  • PJPayne
    Offline / Send Message
    PJPayne polycounter lvl 5
    Oh that helps so much, didn't realize I had to exaggerate the high poly even more, interesting!

    I am confused about unwrapping on the hard edges though, does that just make it so less errors occur when baking or is it something else?
  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    Exaggerating the highpoly isn't what solved the issue, but jsut gives a nicer result. You'll be able to see the benefits of your normal map bake much further away, rather than exclusively extremely upclose. The unwrapping part is just to follow along this golden rule for baking hardsurface/any asset really: 


  • poopipe
    Offline / Send Message
    poopipe hero character
    Can we just sticky that image at the top of this forum? 
  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    poopipe said:
    Can we just sticky that image at the top of this forum? 
    That, and possibly "your cylindrical details need more subdivisions"
  • Shrike
    Offline / Send Message
    Shrike interpolator
    the image implies that nr1 is the only way to unwrap this properly which is not correct tho, and its the worst way performance wise

    Smoothing splits just need to be where the UV islands are split
  • rollin
    Offline / Send Message
    rollin interpolator
    Shrike said:
    the image implies that nr1 is the only way to unwrap this properly which is not correct tho, and its the worst way performance wise

    Smoothing splits just need to be where the UV islands are split
    I would argue there is not one preferred cube. 
    The example is just a 2 by 2 matrix of all relevant possible combinations
    Of course you can argue that, to make it 'more complete', the example could be extended by a half-hard / half-smooth cube
  • Shrike
    Offline / Send Message
    Shrike interpolator
    There is not one preferred cube but all these examples are not part of any of the preferred cubes as these are all bad
    (which I learned recently) Only one shades correctly but thats still a bad unwrap

    Now thinking about it, Max only has smoothing groups but no smoothing splits right? So can you split this properly at all in max?



    Here are varied methods that all can shade right if you have your tangent space matching and your smoothing splits where your UV splits are

    Although some are more prone to cause errors (the one with the less cuts) under non ideal tangent spaces



    but as you can see, the vertice count is really bad for the total split one

    Its been some time since I used max but can you even get such splits without having all faces exploded?
  • rollin
    Offline / Send Message
    rollin interpolator
    The shading of the cubes is maybe just like it is because the one making the image did not bake and display them with the same tangent space. At least that's my guess. This is obviously misleading as it did mislead you.

    All 4 cubes are technically valid but visually it makes sense to say the one with the visual black borders is artistically done "wrong"
    What I think is good to see is: with smoothing groups the normalmap has to counter the model's normals a lot more. And this can lead to banding, problems with LODs, etc.

    So I always try to make as less uv-cuts as possible. You then add hard edges where the gradients on the normal map become a problem.

    Regarding max: you can set one face to multiple smoothing groups. That way you can make mixed hard and smooth edges for one face and its neighbors 

    And btw.. if you "just learned" something you should consider that you maybe not learned all of it yet ;) So be cautious with making statements. But I appreciate that you did setup a test case!
  • FrankPolygon
    Offline / Send Message
    FrankPolygon polycounter
    As Till mentioned: there's other factors that are causing problems with the last two cubes in the example image. These could be mismatched tangent spaces, flipped triangulation, strong horizon occlusion or some combination of issues. The first two cubes in the example image are sufficient to illustrate the point. The last two cubes are slightly disingenuous and that does dilute the message.

    Context is important: the original discussion is about the use of hard edges and how they need to be supported with UV splits. This is the "rule" that's illustrated by the example image that Eric posted. The example image, despite it's narrow scope and technical issues, clearly implies that [when baking normals] UV splits need to be added wherever hard edges are used. Sound technical advice.

    The UV layouts and smoothing on the other cubes can all be validated with test bakes. If the hard edges fall along UV splits (or uses a single smoothing group without hard edges) the mesh should bake correctly.

    When it comes to placing hard edges (smoothing groups) and UV splits, some strategies will result in strong normal map gradients. These normal map gradients can produce shading artifacts. Normal map gradients can be controlled and reduced by adding hard edges, additional support geometry and (in some cases) using custom normals. What's best will depend on the project's overall goals and technical limitations.



    Both UV seams and hard edges will split the mesh so neither on their own are "free" but adding hard edges over existing UV seams is "free" since the geometry is already split. While the vertex count is higher than reported (when accounting for the doubled vertices along the UV splits) the difference in practical applications is less radical.

    All of these unwrapping samples will work but what's "right" or "best" will depend on the scope of the project. This is where the trade-offs between texture distortion, mesh shading and performance are made. Assets used in simple examples tend to be more conceptual and less exhaustive. Which is why simple shapes are great for teaching concepts but aren't suitable analogs to more complex assets. What's right for an individual asset will largely depend on artistic and technical limitations.



    The use of hard edges [to control smooth shading and baked normal gradients] informs the use of UV splits, not the reverse. Hard edges need UV splits but UV splits don't necessarily need hard edges. If an asset needs hard edges and a robust normal map with minimal gradation then having the additional UV splits and the associated increase in vertex count is just the cost of that trade-off.

    Meshes are split by both UV seams and hard edges. Once the mesh is split, it's split. The performance cost is already there. Take advantage of this and look for natural breaks in complex shapes and use these breaks to place hard edges and UV seams together. This will help minimize performance costs, texture distortion and normal map color gradients.

    Try to strike a balance between technical performance and visual performance. What's going to work best will depend on the shape of the mesh and the context in which it's being used.

    Alec Moody's video on controlling shading behavior is a great primer for this topic:

    Additional resources can be found in these pinned topics that cover various aspects of normal map baking:
    https://polycount.com/discussion/147227/skew-you-buddy-making-sense-of-skewed-normal-map-details/p1




  • rollin
    Offline / Send Message
    rollin interpolator
    Good post Frank,

    I should add as a side note (as this is more of a technical aspect but part of an area I'm interested in) that the vertex split from uv cuts and hard edges results from the way today's realtime rendering works. This is not just some magic fundamental rule that just _has_ to be.

    The shader will process the model vertex by vertex. And every vertex comes with it's own set of discrete data like normal vector (encoding the hard edges) or the uv-coordinate. (Note that a vertex can have multiple uv-coordinates but not for the same uv!)

    But as your modelling tool most likely can store multiple uv-coordinates per vertex (in fact probably storing them per face)  the model has to be manually pre-processed. Usually this happens in today's engine's "editors" (at least in unity) or when exporting to some proprietary engine format or if you use some older 3d file formats like 3ds.
    During this the model will be split at uv borders and hard edges.
    And, generally speaking, also at any other data which should not interpolate between faces like per-face vertex colors. Because today's realtime rendering is great at interpolating but very bad at not doing so ;)

    If something is wrong here pls. correct me!
  • Shrike
    Offline / Send Message
    Shrike interpolator
    I surely dont know all but the claim of the list being a 2x2 matrix of all relevant combinations needed to corrected because none of the combinations were good. The first has really poor UVs and performance although looks right, the rest has (intentionally) shading issues or seams.

    It just comes down to the smoothing splits vs the UV splits to look correct assuming ideal tangent space - but it still requires caution at the more heavily distorting layouts (in Unity under matching tangent space not all have worked fine per example), but given the brutal cost of the total explosion of faces method - in terms of vertices, UV space and ease of painting, it really should be tried using a better unwrap method
  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    @Shrike

    "Now thinking about it, Max only has smoothing groups but no smoothing splits right? So can you split this properly at all in max?"

    Yeah absolutely, you could split it with a single button click in Max.

    Also, I do remember seeing your previous thread. Regardless of syncing tangents and having it shade correctly etc. etc... At the end of the day, aren't you going to have ridiculous gradients in your normal map/low-res mesh when you're baking the more 'optimal' way of stitching things together splitting the UV's with larger chunks? Especially the example of those rectangular shapes, since they're extreme 90 degree angles being smoothed together.

    Surely that sort of issue in your normal map (which greatly affects your meshes when it gets mipped/compressed to smaller textures) outweighs the performance hit of more smoothing splits to reduce that sort of artifacting.
  • Shrike
    Offline / Send Message
    Shrike interpolator
    Some people in that thread were adamant on that it can all be perfect but personally Im not convinced with the more crazy stretched versions, at least in unity Mikkt space it did not work as well as in marmoset and I heavily suspect varied other cases won't be optimal either. Also if you model for others or sell assets its definitely a significant risk but there are still methods that do not involve total explosion and work consistently.
  • rollin
    Offline / Send Message
    rollin interpolator
    Shrike said:
    Some people in that thread were adamant on that it can all be perfect but personally Im not convinced with the more crazy stretched versions, at least in unity Mikkt space it did not work as well as in marmoset and I heavily suspect varied other cases won't be optimal either. Also if you model for others or sell assets its definitely a significant risk but there are still methods that do not involve total explosion and work consistently.
    What you are saying is: "gradients on normal maps make other existing problems even worse" which is quite the correct observation ;)
  • Shrike
    Offline / Send Message
    Shrike interpolator
    poopipe said:
    The harden, split and pad approach is safe, reliable and all but eliminates problems with Lodding and compression that are rife with the other approaches. 

     A few extra vertices worth of data means absolutely bugger all  in terms of performance so that argument is completely moot.
    The texture cost of padding is usually minimal assuming you're working to a spec texel density so that's moot too. 

    It's true to say that it does not give you the highest quality on your top lod but it will give you the overall best quality on an in game asset.

    (Just to be sure you mean the 24 verts example right)
    So you are just exploding everything by angle?

    With "Few extra vertices" you mean 50% more vertices than the perfectly baking 16 verts one and 70% more vertices than the 14 verts one

    Not to forget the insane waste of UV space (must be easily 40-60% less texel density at the same resolution) and the total clusterfuck that is your UV with an exploded approach. Surely it depends on the assets but on ours that would be crippling and unacceptable, then Id rather spend the 20min and split them as little as needed.
  • rollin
    Offline / Send Message
    rollin interpolator
    You can of course do what ever you like with your own assets.

    50% more vertices is what you get from this specific worst-case cube-example.. So if not all assets in your game are worst-case-cube-examples... 
    also
    40-60% wasted uv-space seems also bit.. much? Not sure how you came to this value but uv-splits don't need that much room to work. Even with the 50%-cube. It's not the same as you would do for mip-mapping-save padding at the 'usual' other uv-cut - as far as I know.

    But anyway... It seems you've made up your mind already.. But for others who might stumble upon this thread..
  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    If anything really, UV splits on large, strange shaped UV islands allow them become more packable and manageable... :shrug:
  • Shrike
    Offline / Send Message
    Shrike interpolator
    Its hard to calculate but by eye but all the solo quads do waste and clutter an extreme amount in padding

    And yes I sure have made up my mind, its significantly worse in performance, texel density and uncomparable in terms of usability in case you want to manually edit things

    I just made a quick test on a batch of assets which are pretty varied and should be a good test case, 
    The vertice count has not been that big of a difference however as I thought, more around 10% here [20741 vs 22774 verts] (50% would be worst case if everything is just made of 6 siders) but the texel density is far worse than I expected:

    I get 2.5x more texels with the better unwrap 
    Lets say I did not unwrap the second one perfectly, there are some uneccessary splits on cylinders but its still easily Factor 2 difference - thats the difference between a 2048x2048 and a 2048x4096






    My padding is also very tight there, the exploded unwrap would become noticeably worse again with more padding. But I'm of course very open to see some of your test cases.

  • Kanni3d
    Offline / Send Message
    Kanni3d greentooth
    You're getting a huge hit in less TD because of the enormous amount of tilted/angled UV's in the split uv example... Gotta straighten them out, and I guarantee a much better TD result at the least. :grin: Idk man, I think vert count in engine an extremely negligible factor in performance nowadays, especially when you weigh it against having wonky bakes and normal maps.
  • poopipe
    Offline / Send Message
    poopipe hero character
    I applaud the fact you've looked into this to the depth you have - I wish more people did that rather than accept the first 12 year old answer they got from Google but if you do everything else right your concerns are really a non issue and if you don't do the other stuff right you have bigger problems than vertex count increasing due to uv splits and the occasional slightly larger than ideal texture. 

    It's probably worth pointing out that several smaller maps is usually a better idea than one big one if you have texture streaming In your engine and that even 2k maps should be questioned if you're targeting consoles. 
  • Shrike
    Offline / Send Message
    Shrike interpolator
    I do not get wonky bakes with the 2 group unwrap but with all 1 group ones definitely
    Didn't think about straightening, good call

    Just tested with straightened UVs and the difference was only around 4% against the randomly angled packing
    I think that advantage is lessened the larger the sheet. Tiny bit better but still drastically inferior to the minimum amount of splits approach. It depends on the split.

    Ah, I also made a mistake, the exploded one is 23388 Verts versus 20741
  • rollin
    Offline / Send Message
    rollin interpolator
    C, you get some additional vertices but not 50% more. If you want to spend them is something we have decide from case to case. If it's worth it then.. well it's worth it. If not then not.

    About the (I guess automatic) unwrap example you posted: I can't perfectly see what's going on there because of the amount of pieces but if this is an automatic unwrap this is what I would expect. Because you have many (!) parts and all (!) get the same padding. So the more parts you have the more % of uv space is used by padding.
    A math person would say: if you push the count of elements to infinity the uv-space used by padding goes to 100% (if the absolute amount of padding doesn't change of course)

    If your workflow requires automatic unwrapping with many pieces on one texture and you can't split after unwrapping then this is a valid concern
Sign In or Register to comment.