ValleyTree source-colour correction

Published on 16 September 2026, limited to ValleyTree_color.png in ArtSource/Alps/Exports and Assets/Rampage/Resources/Textures. The previous files and importer meta are archived byte-for-byte in ArtSource/Alps/ValleyTreeColourRepair/Before. No mesh, UV, material tint, alpha cutoff, importer setting, lighting or fir texture was changed.

The old Blender exporter read the publisher colour through Blender's linear pixel buffer and wrote it into a generated image. Across 152,988 fully opaque pixels in the entire used UV rectangle, every old RGB value lies within 2/255 of the linearized publisher source. The current Unity importer has sRGBTexture: 1, so it decodes those values again. This is a local export/encoding fault, not an exposure problem. Semi-transparent edge values also contain merge/unpremultiplication differences.

CPU Blender inspection of the retained blend and all three delivered FBX LODs confirms identical leaf UVs: U=0.015..0.438, V=0..1, split at V=0.5. No atlas transformation is required. uv-audit.json and the 32-cell pointwise results in colour-repair-manifest.json record the complete checks.

The correction copies the original publisher RGB bytes exactly and preserves every existing runtime alpha byte exactly. Publisher source: Tree Small 02, Rico Cilliers / Poly Haven, CC0. This remains the existing fictional broadleaf adaptation, not a botanical identification.

prepare_valley_tree.py now invokes merge_valley_tree_colour.py: a direct Pillow/numpy channel merge, with nearest conversion of the original 16-bit alpha to 8-bit. That rounding reproduces all old alpha bytes. The helper was executed into staging and reproduced the corrected PNG's exact hash. Both scripts passed syntax checks. A full geometry export was deliberately unnecessary; Unity/native image validation remains Root-owned and pending.

The helper uses RAMPAGE_ART_PYTHON if supplied, otherwise the existing bundled art runtime, then a system Python fallback. The selected Python must have Pillow and numpy; no automatic package installation occurs.

A bounded read-only check also verified that runtime FirNeedles, FirBark and FirTrunk RGB bytes already exactly match their publisher maps; this conversion fault does not apply to those textures. The separate new whole-tree broadleaf atlas is unchanged.

Native follow-up: 03:12 combined build

Docs/QA/20260916-031207-campaign passed both rendered functional drives (2/2), but Root and the independent image review rejected the combined visual result: the restored publisher RGB together with the previous near-tree material tint produced conspicuously pale yellow-white crowns. This does not invalidate the byte/UV proof above or change the historical publication record: the source-colour correction remains in place.

Root subsequently changed only ChapterAssets.Foliage's authored SetColor tint from (0.72, 0.82, 0.62) to (0.43, 0.55, 0.40). These are material colour inputs, not claimed direct linear reflectance measurements. The new tint is a separate art candidate, untested at the time of this entry. The existing published.json and source-correction evidence were not rewritten to imply acceptance.

Native follow-up: 03:21 tint candidate retained

The 03:21:27 build, assembly SHA-256 390C119AC94E74B13D635A56CF3EEB26461331AC6FA0018194DAB6C8F54B62A6, passed the rendered Alps01 drive 1/1 in Docs/QA/20260916-032128-campaign. Root personally reviewed alps-01-pass0-view0.png and alps-01-pass0-view1.png: the near crowns are green again, with the previously pale yellow-white appearance absent. The separate (0.43, 0.55, 0.40) tint candidate is therefore retained as an incremental visual improvement. This is not photorealistic/AAA acceptance or complete campaign validation. The earlier rejected result and source-colour proof remain unchanged historical evidence.