Hello guys,
Not sure if this is better placed in Engine Source & GitHub but as it concerns mainly rendering, I just put it in this forum section.
So the problem is, that with dense meshes, the engine “optimizes” the meshes render data, espeically the vertex normals, and well, put it simply, makes reflections on those dense meshes look bad.
This thread is not about whether the meshes could be optimized. The whole thread is under the condition that the mesh data (and its density) CANNOT be reduced!
Anyway, @RyanB already stated the problem in this thread: https://forums.unrealengine.com/showthread.php?98518-Reflection-Banding-on-Concave-Metallic-Surfaces that the normal data gets packed into a 4-component vector of uint8 size which hurts accuracy
So, I of course went forward and tried an initial approach:
- replacing the FPackedNormal types with FVector4 (because the packed normal consists of 4 components, too) for static and dynamic meshes. I limited it to mesh-related instances.
- replaced the VET_PackedNormal EVertexElementType enum with VET_FLOAT4, i guess this is for the actual render ressources and needed?
- I went forth and fixed all the compile errors that arose from my changes, mainly typo stuff for example: TangentX.Vector.W to TangetX.W.
- I bumped the static mesh version number because I ran into problems when it tried to cache old meshes (my understanding of a GUID is that I just change the last literal and the version number is “bumped”?)
My problem is, that my knowledge of the engine is still limited in terms of C++ and whenever I try to compile the engine, i trigger a breakpoint because of some serialization problems.
My questions are:
- Is this approach alright at all or should I use another data type instead of FVector4? Should I maybe just try to increase the FPackedNormal size to unit16 per vector component?
- I read some warnings about TArray::BulkSerialize() and i am not sure whether they apply for FVector4 or my case in general
- What do I have to do in order to get the serialization process for the new vertex normal/tangent size to work?
- Some general guidelines about this problem would be great
- In case FVector4 is applicable, what kind of performance hits are to be expected? Can it be that bad?
Assertion failed: SerializedElementSize == 0 || SerializedElementSize == ElementSize …\Engine\Source\Runtime\Core\Public\Containers\Array.h] [Line: 1262]
Expected 64, Got: 36
CallStack:
>
UE4Editor-Engine.dll!TArray<FModelVertex,TAlignedHeapAllocator<0> >::BulkSerialize(FArchive & Ar, bool bForcePerElementSerialization) Line 1262
UE4Editor-Engine.dll!UModel::Serialize(FArchive & Ar) Line 276
UE4Editor-CoreUObject.dll!FLinkerLoad::Preload(UObject * Object) Line 3175
UE4Editor-CoreUObject.dll!EndLoad() Line 1245
UE4Editor-CoreUObject.dll!LoadPackageInternal(UPackage * InOuter, const wchar_t * InLongPackageName, unsigned int LoadFlags, FLinkerLoad * ImportLinker) Line 1042
UE4Editor-UnrealEd.dll!UEditorEngine::Map_Load(const wchar_t * Str, FOutputDevice & Ar) Line 2374
UE4Editor-UnrealEd.dll!UEditorEngine::HandleMapCommand(const wchar_t * Str, FOutputDevice & Ar, UWorld * InWorld) Line 5897
UE4Editor-UnrealEd.dll!UEditorEngine::Exec(UWorld * InWorld, const wchar_t * Stream, FOutputDevice & Ar) Line 5391
UE4Editor-UnrealEd.dll!UUnrealEdEngine::Exec(UWorld * InWorld, const wchar_t * Stream, FOutputDevice & Ar) Line 743
UE4Editor-UnrealEd.dll!FEditorFileUtils::LoadMap(const FString & InFilename, bool LoadAsTemplate, const bool bShowProgress) Line 2014
UE4Editor-UnrealEd.dll!FEditorFileUtils::LoadDefaultMapAtStartup() Line 3215
UE4Editor-UnrealEd.dll!FUnrealEdMisc::OnInit() Line 299
UE4Editor-UnrealEd.dll!EditorInit(IEngineLoop & EngineLoop) Line 86