Second /detailed normal map blending to provide seamless look over hard edges/uv splits ?
Is there a proper normal map blending for "detailed" second normal map that could preserve rounded look oh hard/split edges .
It's "overlay" blending in Blender for example . It looks even worse in game. Detailed normal map reveals the hard edge seam instantly. I use same tangent space /UV island orientation in both normal map layers . Add/sub blending looks more or less same. Wonder if there is a perfect way that could preserve perfectly seamless look over hard edges the first (unique ) normal texture provides? A kind of tricky vector math that could do it?
ps. I tried several approaches Google found , like so called NDM and RNM . Fo the later I couldn't understand a thing what it's actually doing so perhaps recreated it wrong maybe . So wonder if it's at all possible to be seamless over hard edges or the second layer would always mess it whatever blending I could try?
Replies
I don't think any of the standard shader based blending will solve this - the detail map doesn't know anything about the other normal map, it's just using the mesh/uvs to determine what direction pixels point in and then blending the result.
good solutions for this would effectively be prebaking the blended normals and then applying them in a single pass. I'm not sure that's actually doable in a pixel shader - it might be possible in blender with some sort of composite node.
overlay isn't a great way to blend two normals but it's far from the worst.
the usual disclaimer - not a graphics programmer
Well, it would also be good to identify why there is a "rounded look on hard/split edges" to preserve to begin with ...
Do you mean that a hard edge that was intentionally placed in the middle of a smooth surface of the ingame mesh, and was being compensated by a normalmap ? If that's the case then best course of action (if possible of course) would be to scrape the current bake altogether and redoing it with a healthier setup not involving unneeded hard edges. Which in turn has the potential to lead to sterile arguments with whoever decided to do things that way in the first place ...
No. I am trying to make a high rocky wall along a road from a laser scan . The object is too big for unique unwrap or would need gazilion UDIMs . So I am doing it as a mix of more or less uniqu big parts + second tilable "detailed" layer.
The first layer is usual baked unique texture from a laser scan. With typical hard edge splits or rocks corners . Baked normal map perfectly hides the straight hard edge corners. But the second "detailed" normal map reveals them back badly.
in fact I found that in Blender it works just fine if the second normal map doesn't have much of extreme gradients like in test spheres I tried initially.
And the blending method is irrelevant in Blender. In this screen it's just do sub /add for example ( for R and G ,and no blend for Z ) . But in our game I see no trace of first layer normal map , the "detail" one kills the first one completely whatever blending we try. Wonder if someone ever had similar issue? What may cause it ?
Hello,
"The first layer is usual baked unique texture from a laser scan. With typical hard edge splits or rocks corners . Baked normal map perfectly hides the straight hard edge corners."
Well doesn't this confirm that this asset does have have unneeded hard edges though ? There is no justifiable reason for a 3D scan to introduce such hard edges - meaning that someone at some point in the process decided to put them there either manually or automatically for whatever reason. This could come from flawed reasoning from the engineers who developed the scanning procedure, or some roundabout way to compensate for an issue somewhere else in the engine or in the pipeline, or a mistake happening sometime in the conversion process from one file type to another like with the classic case of an importer deciding to read UV splits as vertex splits.
So from there I would still maintain that the healthy, most simple way to go at this would be to go back to these lowpoly assets, remove their unneeded hard edges, and convert their normalmap accordingly (which is pretty much a two minutes process in Blender). And from there even though the engine you are using has limitations that may or may not be fixable, you'll have a much more healthy basis to do tiling texturing, even without a baked normalmap underneath.
you may be able to circumvent the issue by using height in place of normal detail. (edit: oh... nevermind)
same problem - the resulting normals will be in the space defined by the mesh uvs/tangents- not the space defined by the unique normal map.
pior is right - a more sensitively constructed low poly will solve this.
Thanks guys . The reason I use typical hard edges is they are much easier to do lods with . Shading stay same vs beveled geo + face weighted normals . And the process is more streamlined. I usually just apply split hard edge modifier then UV unwrap then merge vertexes back in an automated manner without much of manual UV seams placing through a huge extent of this rock wall . Also our forwarded style low res shadows , especially self shadows are kind of more connected to surface with hard edged geo. Shows less artifacts .We have no contact shadows Blender and Unreal do.
Still the beveled geo is probably a way to go. Thanks for the advice Pior.
Well ... outside of the LOD aspect (which imho isn't the most convincing ...), the part about using a Split Hard Edge Modifier to avoid manually placing UVs doesn't make sense, since the algorithm used to split edges by angle is the exact same used by the "Select Hard Edges" command (which, admittedly, is the worst named command ever since it absolutely doesn't do what it says) to find edges by angle. So instead of harshly destroying the model and merging back together later which is really quite dangerous, you could filter for these edges automatically and non-destructively and do whatever you want with them.
Split Edges Modifier set to 30 degrees on the left, and Select Hard Edges set to 30 degrees on the right :
Overall outside of reasoning for or against doing things a certain this really goes to show that the most important thing is to figure out the whole "tech stack" required by a project before committing to a workflow. IE preproduction.
Also at the end of the day everything is a matter of perspective : if the game you are working on relies so much on the LODs having a certain look and shadows catching well onto hard edges for a bold image, then sure enough worrying about a faint discontinuity in the detail nmap when looking at a model up close seems quite irrelevant. It's hard to tell though as the screenshots in this thread are very cryptic and hard to decipher (showing nothing of the aforementioned shadows and LODs, showing a temporary tiling detail map made of spheres instead of the actual rocky one, and so on). The more effort you put into the presentation of your issue, the less likely you'll end up with something close to a "XY problem" situation...
https://xyproblem.info/
Thanks Pior for the perspective. Yeah. it turned out that detail normal map discontinuity is the least of my problem.