Thank you for investigating my model. I will take it to the modeler here and have them produce a lower-poly version to see if that changes anything. I’ll post back here when I see those results. Hopefully it will be today.
Here is the low-poly model - the banding is definitely “fixed”. The reflection now follows a plausible/physically realistic path and looks much better.
what still bothers me though, even though this is low poly and is improved, is that there is still this “hammered metal” look to what is actually a perfectly smooth surface. The reflection is still not behaving correctly from a physical standpoint, because there aren’t facets on that face, it is a smooth curve and should be reflecting as such. I would suspect my model, of course, since this engine is quite mature, but I’m at a loss to explain why I simply cannot get this reflection looking right when the two other engines we are experimenting with seem to be getting it “correct” right out of the gate?
Hey guys,
I believe DarthViper was correct when he suggested it was the high polygon density. I can shed some light on why that is the case.
Vertex normals are losing some precision when you import. The precision max error is around 1 degree or so. You if you can imagine, if you have a sphere more tesellated than that, some of the verts will have the same normals. When you have less tessellation, none of the verts get shared values, but then you get linear interpolation of normals across faces. That is what causes the ‘hammered metal’ look above. To fix that would require some fancy and expensive method of interpolating normals.
This became a big issue for some internal prototype project. They realized that UVs actually store with more precision than vertex normals. So for cases where you really need high quality vertex normals and hi poly meshes, you could consider an option like that.
Another way to fix this in your case would be to make that ‘sharpened’ side part of the knife as flat as possible. Right now you are trying to model a vert slight curve across that whole area, and such subtle curvature doesn’t hold up well. You could also try to just project flat normals onto those areas in the shade. You could use math to make the normals a bit rounded if you need that look.
@, thank you for the well explained response. Those points make a lot of sense. With that knowledge, we will go make some adjustments to see what happens. Thanks for your response!
Final update - we worked through our model this afternoon, and about 30 iterations later, learned a lot about importing things to Unreal. This is the sum up of what we learned:
1.) Low Poly matters - not just due to FPS and memory size. Too many vertices doesn’t seem to allow Unreal to do interpolation of the reflection with a high quality. Lowering the poly count from our original high-poly model caused the banding to go away.
2.) Triangulation within the modeling program (3DSMax) matters - tessellating the mesh within Max controlled the triangles to not be too skewed/stretched out. This seemed to help the quality of light reflection be more smooth. This also assisted in eliminating the strange curve-banding in the reflection
3.) As stated, having faces who have a very small degree of change between them, as in our concave curve to the knife’s edge, reveals an issue in the FBX importer where the importer has a margin of error that is big enough to improperly represent the multiple small angle changes present in the model, causing the transitions between faces to lose their smoothness. This is where the “hammered” effect shows up. We modified our model to have a straight edge and the reflection worked perfectly after that. Although not true to what our model is supposed to look like, it at least helps us definitively know exactly what causes the issue.
Here is a comparison of the straight vs. concave face on the knife blade’s side:
@ Is this optimization still needed with modern games, or is it left over from UE3 or older era optimizations? We have “Use full precision UV” that allows people to avoid precision issues with UVs, will there ever be a similar feature for vertex normals to avoid this issue?
@ How many bits per channel normals(and how about tangents) actually have?
Had to ping Brian Karis who pointed me to FPackedNormal which is the struct used to store normals for rendering. Looks like its simply storing each channel as an 8bit uint.
So the data is there since the rawmesh data is storing the normal as an FVector, but it may be pretty difficult to change the render data to use that due to the number of places it is used.
DXGI_FORMAT_R10G10B10A2_UNORM would go a long way to fix this without increasing storage.(assuming that alpha channel isn’t used right now.)