Trying to bake very seemingly simple Normals in SP2, weird notches and lines on edges appearing??
polycounter lvl 7
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
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
https://drive.google.com/open?id=1WGemn8SPvNpohHrMRvplOd5QJ6cHpOyH
Smoothing splits just need to be where the UV islands are split
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
(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?
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
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!
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
"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.
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.
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.
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..
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.
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.
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
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