Summary
Historical observations on UE 5.8.3, CL58210709, Windows show one matched native MeshPartition preview group receiving different build/cache keys across Editor processes despite matching recorded meaningful inputs. The original calculation hashes the complete 72-byte representation of the UV-options object.
The evidence strongly suggests representation-dependent key generation for this sample. This is not a claim that DDC lost an entry stored under the same key, or that this alone explains an editor freeze. Source and caller checks
In the retained original MeshPartitionMeshBuilder.cpp, the key helper hashes sizeof(Type) bytes of the aggregate, including the UV-options object. The key-function body was unchanged in the original-calculation observer build.
The reviewed preview path constructs its settings through FChannelCollectionUVLayoutOptions::GetFromDefinition, followed by the preview UV-quality assignment. The observer covers all 14 named scalar leaves: TexelSize, MaxTextureResolution, GutterTexelCount, UVLayoutMethod, UVQuality; SamplesPerSquareMeter, VoxelCount.X/Y/Z, bAcceptOutputOnFailure; NormalSource and FixedNormal.X/Y/Z.
The recorded values are finite and matched at the retained float/double formatting precision. No omitted named semantic field was found in the reconciliation. The selected group used Epic’s native BASE modifier, not a custom project modifier.
Reproduction and build-state disclosure
This is evidence from a custom project, not a supplied minimal reproduction. The recorded workflow compared the same selected group in successive Editor processes, correlated an earlier successful write with the next process’s first read, and compared keys and recorded inputs.
The observed runs were instrumented and already contained cumulative scheduling changes and an earlier cleanup guard elsewhere. They must not be described as wholly unmodified-engine runs. A historical field-based implementation was used as a diagnostic comparison; no patch or modified binary is offered here as a solution.
There is one independently matched group. Two emitted observations per process repeat that group; they are not two independent samples.
Limits and request
The exact differing storage-byte offsets were not captured, so padding is a hypothesis, not a demonstrated byte-level cause. A separately pinned historical header is unavailable; the readable type definition reconciles with the historical observer. Other build modes, platforms, newer releases and whole-world prevalence were not tested. A minimal stock-engine project is not attached.
Could Epic inspect this UV-options hashing path for deterministic key construction and advise whether an existing issue or fix covers it?
Attachment: Dropbox a small derived evidence summary, not raw instrumentation or a reproduction project.
What Type of Bug are you experiencing?
Editor
Steps to Reproduce
Reproduction status: observed in an existing custom project; a minimal
stock-engine reproduction has not yet been prepared. The following
describes the historical diagnostic sequence.
Environment: Unreal Engine 5.8.3, CL58210709, Windows, with a
World Partition map using MeshPartition terrain previews.
-
Open the affected map and evaluate a selected MeshPartition preview
group using Epic’s native BASE modifier. -
Using diagnostic instrumentation, record the selected group’s identity,
relevant input identities/versions, all 14 named scalar UV-option
values, the raw UV-options object-storage digest, and the generated
build/DDC keys. Record the cache-write completion result. -
Reopen the same saved scene in a fresh Editor process and observe the
same selected group, without changing its meaningful inputs. -
Compare the recorded inputs and generated keys between the two
processes, and correlate the first process’s successful cache write
with the second process’s first cache read.
Observed result:
The recorded semantic UV-option values and other matched inputs were
equal, but the raw UV-options object-storage digest and resulting keys
differed. The second process’s first cache read was non-Ok under its
different key, despite the earlier process’s successful write.
Expected result:
Equivalent meaningful inputs should produce the same build/cache key
across processes, allowing the previous result to be reused.
Important build-state disclosure:
These were instrumented custom-project runs. The original UV key
calculation was retained during the failing comparison, but unrelated
scheduling changes and an earlier cleanup guard were already present.
This is not claimed as a wholly unmodified-engine reproduction.
The evidence covers one independently matched native preview group.
The exact differing storage bytes were not captured, so uninitialised
padding remains a hypothesis rather than a demonstrated byte-level cause.
Expected Result
Unchanged meaningful inputs should produce a repeatable key, allowing a previously completed result to be reused across processes.
Observed Result
Two cross-process comparisons were retained:
see attached image.
The original full build keys were:
77f4c286db9885110ce4487f9e5b997535897a5d1ceb96a1d124d909e8dc25cc
76eeaa871a118411cab1e3465612290d803c44f1601e3a488d5d7ab718650266
The field-based comparison used accab7fb417dad8d14eff717ae681b633696bbc3d6abf8fbbf438ae9e6ec5a2a in both processes. These are full build keys, not the separate 40-character derived DDC keys. Before/after keys need not match because the historical algorithm changed; the relevant result is consistency within each cross-process pair.
Affects Versions
5.8
Platform(s)
Windows
