From Multi-State Photogrammetry to Interactive Environments: Coordinating Geometry and Appearance in Unreal Engine 5

1. Introduction

A physical object can be recorded in several observable conditions: its surface geometry, coverage and material appearance may all differ between captures. Multi-state photogrammetry preserves these observations, but separate reconstructions do not by themselves provide a controllable object for an interactive application. The ODD INN project addressed this connection through a field campaign with the objective of scanning an entire open-air museum in summer and winter and turning the acquired states into an environment that changes through player interaction.

The acquisition report records ten large photogrammetry sessions and more than 2 TB of campaign data, comprising RAW photographs, developed images, RealityCapture projects and 3D exports. It states that substantially more than twenty objects were captured in two states, with twenty selected for quality and suitability for system development [P16]. Twenty is a selected development subset, not the total acquisition extent. The stage-4 report identifies the Museum of Folk Architecture in Sanok (Muzeum Budownictwa Ludowego w Sanoku), Poland, as a source location for objects represented in the environment’s model collection [P05]. The subsequent game scene combines acquired assets in a newly composed settlement; its report refers to scans from open-air museums and explicitly describes rearranging them [P03]. The record therefore establishes a substantial acquisition campaign and an authored environment, without verifying exhaustive coverage of one museum or its reproduction at a metrically faithful layout.

The implemented workflow connects three stages. Photogrammetry reconstructs the observed conditions of the same objects. Offline fitting and preparation in Blender provide compatible geometry, deformation data and paired appearance inputs. Unreal Engine then interpolates those prepared inputs and exposes the transformation to authoring controls and gameplay [P01, P07]. Correspondence is prepared before import; the running game does not align independent scans. This separation allows a captured difference to become an editable scene property.

The resulting demonstrator, Odmieniec, connects the prepared assets to sliders, selected-object controls and spatial effects. The player can use a freezing projectile, an expanding cold sphere or a scene-wide transformation. Development reports describe completing all three scenarios after object placement and effect settings were edited; retained recordings show asset transitions, a configurable local group and the sphere sequence [P05]. Related environment assets are commercially distributed on Fab [1]. The game is the application result of the workflow, while commercial distribution is a separate dissemination outcome.

This article evaluates the runtime integration within that single capture-to-interaction development. Its companion article examines correspondence and offline preparation in the same system. Here the information-system problem is to keep geometric and appearance changes coordinated while controls select their recipients, spatial extent and retained scene condition. Unreal Engine supplies interpolation, material parameters and serialization; the contribution is their implemented connection to the prepared capture data, the scene controls and gameplay.

Two research questions organize the study. RQ1: How does the implemented system connect prepared multi-state data to coordinated geometry and appearance under object, group and spatial controls? RQ2: Which transformations and interactions were achieved in the seasonal application, and what constraints emerge from its integration, tests and demonstrations? We present the asset-to-interaction architecture and evaluate compatibility, recipient selection and intermediate appearance. Supplementary source and media analyses make the implemented connections and observed behaviour explicit. Seasonal capture is the demonstrated case of the broader multi-state problem. Morphing produces a rendered transition between prepared observations; it does not measure the physical process or the accuracy of change between capture dates.

2. Related Work

Photogrammetry-to-engine pipelines are established. Apollonio et al. describe a museum workflow connecting capture, processed geometry and derived maps to physically based presentation and interactive navigation in Unity [2]. Wen et al.'s Quaddle 2.0 toolbox generates controlled variations of geometry and appearance in Blender and exports assets for applications including Unity [3]. These studies provide relevant preparation and integration precedents. Quaddle's generated feature variations should not be equated with transitions between two scanned conditions of a physical object, or with continuous morphing performed by its runtime engine.

Ludwig et al. jointly morph shape and view-dependent appearance from photogrammetric objects, precomputing intermediate reconstructions that support subsequent interactive viewing [4]. Here, prepared common-mesh deformation and endpoint materials are interpolated at runtime and connected to scoped controls and gameplay. No comparative quality or speed advantage is inferred.

Epic's Unreal Engine 5.2 documentation describes both FBX morph targets for skeletal meshes and a static-mesh workflow that stores deformation in UV channels and applies it through World Position Offset [5,6]. The latter includes scalar-controlled interpolation and provides an established capability directly relevant to the representation used here. The project's early skeletal prototype and later material-driven static-mesh implementation are therefore distinct adaptations of existing facilities [P02]. Neither UV-carried displacement nor Lerp is claimed as a new primitive.

Material Parameter Collections distribute shared values across materials, with documented examples involving snow and morph states; Custom Primitive Data provides per-primitive values, and Material Layers supports reusable material composition [7,8,9]. SaveGame stores application-defined data that application code must restore to scene objects [10]. These facilities explain the available mechanisms. The case contribution concerns the prepared asset contract, the scopes and interactions of its controls, and their working integration with gameplay and persistence.

The winter application also differs from snow simulation. Reynolds et al. model occlusion-based accumulation through height maps, projection, view-dependent tessellation and changes to geometry and colour [11]. Cordonnier et al. generate time-evolving snow-covered landscapes using a heightfield with multiple snow layers and interactive controls [12]. ODD INN instead interpolates prepared endpoints and controls where their transition appears. It does not predict accumulation, melting or conservation of mass, so those methods are contextual prior work rather than equivalent performance baselines.

For interactive information systems, the separation between represented state, synchronization and validated commands is also significant. Solanes et al. describe a layered industrial-metaverse architecture connecting a digital twin with a physical programmable logic controller; the principal evaluation uses a digital representation of the supervised process [13]. Its control and synchronization problem differs from prepared scene assets. It nevertheless clarifies why an application-level account should identify where state is held and how commands affect it, rather than merely list the underlying platform features. The present case supplies that account for coordinated asset transformations.

3. System Study and Evaluation Method

3.1. System Development and Evaluation Scope

The study concerns one system developed from multi-state capture through offline preparation to interactive rendering. Its evaluation follows that chain: prepared-data and material connections explain the transformation, integration checks test the addition of assets, and controls and gameplay scenarios exercise the system in use. Development-stage tests are recorded in reports, QA workbooks, profiling captures and demonstrations. Supplementary analyses in 2026 examine the source implementation and retained recordings, together with a bounded offline compatibility check. These analyses extend the assessment of the same system; they do not constitute a new implementation or a repeated Unreal experiment. The runtime-focused analysis here examines offline preparation to establish the data interface received by the application.

The released implementation supplies the original Python source of OddInn Tools 1.0.0 and selected editable Unreal assets, including two ClayPot examples, the morph material/functions, local and spatial controllers, and save-system structures [14]. Static source inspection followed coordinate assignments and UV writes; inspection of native packages followed named imports, parent references and serialized material-expression inputs. The selected package hashes were checked against the release manifest. A bounded reader preserved byte offsets, export indices and undecoded property payloads in a separate article supplement. It did not execute graphs or supply missing class-default values. The supplementary methodological note specifies this inspection scope and the exact source locations.

Seven development documents cover the application chain: stage-2 milestones 7–9, the stage-3 and stage-4 reports, the code documentation and the system manual [P01, P02, P03, P04, P05, P06, P07]. The acquisition report establishes campaign scale [P16]. Concrete integration, QA, validation and execution records supply additional checks. The supplementary worksheet retains 29 functional, contextual or adverse assertions and adds a separate register of static implementation findings. Goals are excluded from achieved-result coding, and duplicated records of the same activity are not independent trials.

OpenAI Codex (GPT-6; accessed 24–25 September 2026) assisted with collecting, consolidating and analysing project evidence, literature searches, supplementary analysis scripts, and manuscript drafting and revision. Original acquisitions, development-stage experiments and demonstrations were conducted within the ODD INN project.

3.2. Functional Assessment and Media Analysis

For each function, the implementation description and available static findings were compared with the test and demonstration record. Native-asset connections were assigned to their recorded snapshot, without assuming that every earlier recording used identical bytes. Agreement between a manual, a test report and a recording connects the implementation to observed behaviour but does not create independent experimental replications. The supplementary assessment is author-led, without blinded independent coding or an inter-rater agreement estimate. Adverse QA entries and unfilled test-plan fields are retained alongside successful demonstrations.

Three original recordings accompany this version as Supplementary Videos S1–S3: Snow_Morphing.mov (6.53 s), LocalSnow.mp4 (72.02 s), and the stage-4 cold-sphere scenario (51.54 s). Their full temporal extents were sampled, including the first and final decoded frames. The initial schedule requested S1 frames every 0.25 s and S2/S3 frames every 1 s. Inspection then guided denser sampling of visible changes: S1 at requested intervals of 1/30 s over 2.5–3 s; S2 every 0.25 s over 19–24 and 61–63 s; and S3 every 0.25 s over 26–30 s and every 0.5 s over 42–47 s. Each request selected the first decoded frame at or after that time; duplicate selections were removed. This yielded 35 of 196 S1 frames, 94 of 1799 S2 frames and 70 of 1858 S3 frames: 199 inspected frames in total.

All sampled frames were visually reviewed in time order using contact sheets; publication panels and frames used for numerical interface readings were also opened at native resolution. The supplementary media event log organizes the inspection into 18 events and records source hashes, exact frame indices/timestamps, visible inputs, scene responses, camera/group changes and uncertainty. This is sampled observation across each complete recording, not an assertion that every frame or the audio track was examined. It supports assessment of control sequences and visible intermediate conditions, without estimating frame rate, latency or temporal smoothness from video timing. Projectile and scene-wide scenario completion is established from reports; S3 directly documents the sphere sequence.

Historical technical records are available in the versioned repository [14]. The Supplementary Evidence Register identifies P01–P07 as reports/manuals, P08–P11 as material-validation records, P12 as a shader-integration check, P13–P14 as QA workbooks, P15 as runtime-log context and P16 as the acquisition report. De-identified extracts and original/deposited hashes make their coverage explicit. P identifiers identify sources, not trials. The media analysis, event log, functional worksheet and new static-inspection outputs are separate article supplements, distinct from the released historical implementation and repository version 1.1.0.

3.3. Implementation Versions and Supplementary Checks

The preserved project contains editable content and the original scenario maps. The public research release provides a selected component set and its source/configuration, enabling inspection without redistributing the entire game. The project's runtime execution is assessed from its recorded tests and demonstrations; the supplementary 2026 checks did not repeat Unreal compilation, loading or execution. Static links and the separately identified offline compatibility check explain implementation details, while development-stage demonstrations and measurements establish the observed application behaviour. A serialized material-expression connection does not by itself validate the execution of a newly assembled test level.

Figure 1 summarizes the stage-2 material from P01, Figure 18 and its node descriptions. The original screenshot is retained unchanged. The native snapshot described below supplies additional connections from a later implementation stage; those findings are identified separately from the earlier diagram. Notation introduced in this article summarizes these sources; it is not presented as original project code. Historical measurements were transcribed from identified records and were not replaced by new arithmetic checks or static observations.

4. Implemented Transformations and Controls

4.1. Offline Preparation: From Scanned Endpoints to a Compatible Asset

The workflow begins with photogrammetric reconstructions of two observed conditions of the same physical object. These independent reconstructions are fitted and prepared in Blender before runtime use. P01 explicitly identifies the source/target pair as photogrammetric and notes that their textures were generated separately [P01]. Geometry preparation fits a representation to the target condition. The system manual describes retaining the fitted result as a shape key, converting shape-key information into UV maps, and exporting through FBX [P07]. Runtime interpolation therefore consumes a prepared correspondence; it does not match independent scan meshes during play. The records establish this preparation route without providing a complete identity map from every visible game object back to its capture session.

The compatible asset combines reference geometry, encoded deformation and two sets of appearance data. We summarize these dependencies as

$A_i=(G_i,D_i,T_i^0,T_i^1),$where a renderable component i references geometry G_i, deformation data D_i and endpoint material inputs $T_i^0,T_i^1$. Multiple components can reference the same prepared asset while receiving different controls. This notation summarizes the implemented dependencies for the article; it is not an original asset schema or a new algorithm.

The released 1.0.0 preparation operator retains vertex-index correspondence and packs non-basis shape keys in pairs, using three UV layers per pair after the two base layers. It writes local-coordinate differences multiplied by 100 into each polygon corner. An unpaired last key uses zero deformation for the absent second target. The exact assignments and context requirements are specified in the supplementary note [14]. This is a code-level description of the prepared-data interface; the multiplier alone does not establish physical units or verify FBX axis and UV conversion.

A separate 2026 offline check executed this unchanged UV operator in Blender 5.2.0 LTS on six archived KM3 source/result combinations, using one non-basis key and five UV layers. The base-mesh coordinate, vertex/face-order and UV arrays were preserved exactly through Blender–FBX–Blender under the recorded export settings (Supplementary Dataset A1). This checks that preparation interface in a defined environment; it does not rerun fitting, reproduce historical Blender 3.4, establish the provenance of the six-UV ClayPot assets or test Unreal import.

The stage-2 report labels deformation channels 2, 3 and 4 [P01]. In the released native snapshot, MF_StaticMeshMorph has serialized texture-coordinate inputs 3 and 4, followed by a component mask, append and instance-source transform leading to Morph Target 1 WPO. These are identified separately from the earlier diagram. The two released ClayPot meshes reference their material instances, whose parent is m_Morph_01_01; that material calls the morph and snow functions. Both instances reference six endpoint textures. Source inspection establishes this asset-to-material path. The complete texture-parameter binding, capture-session identity and imported-coordinate round trip remain outside the verified chain.

A concrete downstream check follows a newly imported stone-stair model. The tester creates a material instance, connects two texture sets containing colour, surface-relief information and a packed metallic/roughness/ambient-occlusion mask, places the object in the test scene and varies the existing slider between illustrated summer and winter appearances (P12; also reproduced in P04, Section I.3.2, Figures 70–75) [P12, P04]. This is a traceable import–material–control chain for an additional asset. The check does not identify its original capture session or independently document its deformation-channel construction; those upstream operations are described by P01/P07 rather than inferred from the stair images. The two records reproduce one check, not two trials.

4.2. Runtime Coordination of Geometry and Appearance

Development progressed from object replacement (Set Static Mesh) through a skeletal-mesh prototype (Set Morph Target and Timeline) to the material-driven static-mesh representation [P02]. In the refined stage-2 material, the shared State parameter controls texture blending and the displacement path (Figure 1). The documented elementary blend is

lerp(a,b,α) = (1 − α)a + αb,α ∈ [0,1].

Here a,b are compatible scalar or vector inputs. The endpoint asset is illustrated in Figure 2. The equation describes the standard interpolation operation. In the released m_Morph_01_01, four serialized LinearInterpolate expressions—for base colour, normal, packed material properties and World Position Offset—have their Alpha inputs connected to output 2 of the same MF_Snow call. That output is named BlendMask; the function and call have matching output identifiers. The displacement interpolator receives the morph-function output, and the material outputs receive the respective blended signals. This establishes a shared controlling signal in the saved graph, without assuming identical processing after each interpolation or a particular unsaved engine default [14]. The report states that the parameter can be changed in the editor and during gameplay [P01]. An early procedural-noise texture experiment was removed in the refined shader; the later directional boundary uses a separate noise texture. The removal is an implementation change, not an independently measured speedup [P04].

4.3. Transition Controls and Spatial Scope

Table 1 connects prepared asset data to per-component control, shared spatial effects and retained scene parameters. It identifies which controls update the values that drive the transformation.

SetupSnowLevel traverses configured actors and their static-mesh components, writing Local Snow with Set Scalar Parameter for Custom Primitive Data [P04]. The earlier selection slider skips incompatible objects [P02]. These are related control entry points, not evidence that every displayed slider has an identical internal implementation. The local-controller recording makes its editable value and actor list visible.

The controls connect different levels of the same workflow. A prepared material defines how an object can transform; a controller selects the actor components receiving local values; shared parameters describe environmental effects. The recovered MF_Snow contains Local Snow with an explicit Custom Primitive Data flag and Global Snow referencing MPC_SnowParams. These saved inputs supplement the documented actor traversal. The public component selection does not contain the original map instances, so membership of a particular ClayPot in a historical controller group is not inferred. The earlier State parameter and later Local Snow remain stage-specific names.

The manual explicitly states that an object's value cannot be set below the Global Snow level [P07]. Local and global control therefore have a documented hierarchy, rather than unrestricted independence. Source spelling differences are retained in the supplementary methodological note.

4.4. Spatial Effects and Gameplay

Sphere, ray and directional controllers determine the spatial extent of the transformation. The sphere uses its centre, radius and transition-region controls. The ray is oriented from its origin towards the sphere controller, with length calculated in the world X–Y plane. The directional controller sets an origin, orientation, extent and blend distance for an advancing scene transition. P04 states that their masks combine by addition capped at one [P04]:

m(x) = min{1,m_sphere(x) + m_ray(x) + m_directional(x)}.

The individual contributions lie in 0–1 at a fixed controller configuration. Static inspection of the released MF_Snow additionally resolves a local/global segment. A preceding spatial branch feeds an Add node together with Global Snow; Saturate is followed by addition of the CPD-backed Local Snow and another Saturate. With u denoting that preceding branch output, this segment is

q = sat(sat(u + g) + 𝓁),

where g and 𝓁 are the serialized global and local inputs and sat clamps a scalar to 0–1. This notation summarizes the recovered connections; it is not a new algorithm or the complete BlendMask expression. Subsequent nodes apply noise, contrast, brightness and the function's mask input before the final saturation. The final interpolation factor therefore cannot generally be identified with the local slider alone. Remaining defaults and controller-update precedence were not resolved by this static inspection [14].

MF_Snow packages reusable snow functionality and P04 identifies M_Morph_01 as the main base material. The final import manual names m_Morph_01_01; these identifiers are reported in their respective contexts. Directional controls also update configured snow particles and hide configured insect effects [P04]. The environment combines prepared photogrammetric assets with authored vegetation, landscape, characters and effects; it is not asserted that every changing element is a paired scan.

The manual connects the transition system used in Odmieniec to three maps: SlavicYard_P produces a freezing projectile, SlavicYard_P1 an expanding cold sphere, and SlavicYard_P2 a scene-wide time spell [P07]. These are three interaction scenarios in one environment. Figure 3 shows the preserved sphere sequence. Their significance is the completed connection from compatible asset data to player-triggered changes in the game.

4.5. Persistence and Execution Context

P04 describes storing each model's geometric transition value and shared material state, then applying the values to objects and materials when loading [P04]. BP_SaveGame contains local-snow mesh records, shared snow parameters, post-process settings and the monster's frozen state. BP_SaveSystem exposes SaveData, LoadData, GetMeshesWithLocalSnowProperty, WriteSnowParams and ReadSnowParams, using the file name Default [P06]. The manual also describes player-operated save/load triggers. Native serialization supplies a mechanism; the application supplies this payload and its restoration logic [10]. Stable identities after scene edits, atomic restoration and deterministic particle replay are not established.

The stage-2 scene report identifies Unreal Engine 5.2.1 [P03]. A separate September 2023 Development-build log records Windows 10, an i7-10700F, RTX 3070, approximately 64 GB RAM and a 2560 × 1440 viewport, followed by normal Alt-F4 shutdown [P15]. It contains no frame-time series. The later stage-3 scalability section instead specifies an i7-12700K, RTX 3070 Ti and 32 GB RAM. Neither record identifies the configuration of every later capture. The recovered historical snapshot contains the original editable scenario maps, while the public release provides a smaller native component set with its C++ module. The project's runtime execution is assessed from its recorded tests and demonstrations; the supplementary 2026 checks did not repeat Unreal execution.

5. Results

5.1. Achieved Transformations and Playable Application

The completed result is Odmieniec, an interactive environment in which offline-prepared states of photogrammetric assets undergo coordinated geometric and material transformation under authoring and player control. The three spell scenarios connect this asset-level capability to a playable scene. Table 2 separates functions described in project reports from changes directly visible in the retained recordings; these complementary evidence types support functional conclusions rather than numerical pass scores.

The core results in Table 2 are supported by the shader, local-control, final demonstration and integration records [P01, P02, P05, P12]. P05 describes moving and adding scene objects, changing spell settings and then playing each modified scenario. It states that all three scenarios could be completed. These activities connect scene configuration to documented playthroughs. It also reports animation/effect synchronization discrepancies and subsequent corrections, which were not independently replayed during the supplementary 2026 checks.

S2 documents both configuring a local group and changing its state. The controller is placed, actor references are populated and Snow Level is adjusted. The frames at nominal 22 and 24 s display values 0.0 and 1.0 with the same visible camera view and three actor-array entries (Figure 4). A separate native-resolution frame at 20.023 s displays 0.408 and partial coverage. The subsequent sequence extends the array: five entries are visible at 35.023 s and seven populated entries at 56.023 s, when the newly included gate has a white roof. After the camera returns to the earlier group, 62.023 and 63.023 s show values 0.0 and 1.0 with seven populated entries and corresponding changes in visible snow coverage. These observations establish editable group membership and repeated changes in both directions within one recorded session. They are not independent trials or a maximum-capacity test.

S1 supplies the clearest fixed-view record of a group transition. The sampled early frames hold the initial appearance; frames in the 2.5–3 s interval show changing coverage and visible surface outlines, followed by the later condition through the recording's end. Figure 5 presents an earlier, intermediate and later frame at 1.500, 2.767 and 3.000 s. The intermediate view retains exposed regions that are more covered in the later frame, including around the central tree base and the small central stump. The visible group remains in place, and no control value is displayed. The sequence directly establishes an intermediate rendered condition; the connection to geometric deformation and material interpolation comes from the implementation record, not from an inferred three-dimensional measurement of the images.

S3 follows the character through the environment, then shows a Cast a spell prompt at 26.021 s, a casting gesture in the following sampled frames and the visible cold effect around the large creature by 29.017 s. The affected presentation persists in subsequent samples; around 42–47 s the creature's pale appearance changes again. Figure 3 illustrates the earlier gameplay transition. No keyboard-event log, exact mask radius or state parameter is displayed, so these observations record the prompt–animation–effect sequence without assigning measured input latency or a particular value to its material state. The record connects the transformation to an actual playable scene, while S1 and S2 expose the prepared assets and their authoring control more directly.

The stage-2 scene report also illustrates a stump in base, snow-covered and burned-looking conditions in Unreal Engine 5 (P03, Figure 2, Figure 3 and Figure 4), and reports transitions between its states [P03]. These retained illustrations establish an additional demonstrated appearance beyond the winter case. They do not establish a separate photogrammetric scan of a physically burned object, an independently prepared third geometric state or a burning gameplay scenario.

5.2. Quality Observations and Manual Qa

P01 records undesirable intermediate appearance for one of five tested models at parameter values 0.1–0.3 [P01]. P03 describes misaligned seasonal scan bases, normalized pivots and an additional snow effect placed approximately 1 cm above the morphed scanned snow to conceal the mismatch [P03]. These are stage-2 development observations, not an established defect rate for the final game; their resolution for every final asset is not documented. They show why endpoint acceptance and intermediate appearance require separate checks. The presentation correction did not measure improved geometric registration.

The retained scene worksheet contains 36 categorical entries from nine criteria and four testers: 23 “correct”, seven “no load”, four “load”, one “slight load” and one “minor errors”. Comments record hardware-dependent loss of fluidity and absent collisions for three initial models [P13]. The categories are not a standardized pass/fail metric. The final-stage workbook contains 18 criteria and 72 blank result fields [P14]. It provides a test plan, while the completed-gameplay statements come from P05; those two evidence types are not conflated. Neither yields a transition failure probability or repeated save/load accuracy.

5.3. Rendering Observations

Table 3 describes the reported operating context of the demonstrator. The rows are not a controlled comparison of transition methods [P04, P05].

The selected 12.49–16.06 ms values are not the entire observed range: P05, Figure 29 shows a StatUnit minimum of 11.83 ms as well as the average and maximum in Table 3. The same capture separately displays a FrameTime cycle-counter inclusive maximum of 63.11 ms. That counter cannot be merged with the StatUnit average/maximum because the windows and counter semantics differ. Figure 33 records 538 draw calls, including 53 skeletal-mesh draw calls; the different capture in Figure 29 shows 822. These are scene counters, not morphing-only counts. Figure 29 also displays game-AI logging and garbage-collection verification warnings.

Raw CPU/GPU frame-time series were not located in the recovered loose-project inventory, its inspected Saved directories or the four indexed project/build archives. The retained profiling screenshots do not supply repeat counts, durations, aligned camera trajectories or complete resolution metadata. Quality-preset changes alter the rendering task. The observations support interactive operation under recorded configurations, but neither an isolated morphing speedup nor an uninterrupted 60-FPS guarantee; recorded values exceed 16.67 ms. The frequency and causes of slower frames cannot be inferred from screenshots.

5.4. Scope of Quantitative Interpretation

Three historical material-validation exports were examined but were not adopted as accuracy measures [P08, P09, P10]. Their implementation and inconsistent score denominators prevent a reliable interpretation. Six original MS07 view images have since been recovered and released, but a complete matched working-resolution set for the three final reports and its pixel-to-length calibration have not been established. The Supplementary methodological note preserves the printed arithmetic, code limitations and source critique. The present functional results instead rest on the documented implementation, integration checks and observed sequences; no percentage of geometric or perceptual accuracy is inferred from those historical scores.

6. Discussion

The implemented result connects repeated observations of physical objects to a controllable information flow: captured conditions are prepared as compatible asset data, the runtime applies coordinated geometric and appearance transitions, and authoring or player controls select the affected objects and regions. Odmieniec exercises this chain within a composed environment derived from a substantial seasonal campaign. The acquisition scale describes the production context; the local and global demonstration counts describe the subset exercised by the application. These are complementary scales, not interchangeable sample sizes.

The architecture answers RQ1 through a continuous data-and-control path. Offline preparation carries compatible deformation in UV data, the material coordinates geometric displacement and three appearance interpolators through one BlendMask, and local values, group membership and spatial controllers determine where the transition appears. The supplementary source inspection makes those saved connections explicit. RQ2 is answered by the integration and application results: an imported stair asset uses the material/control path, S1 records intermediate rendered appearance, S2 shows group construction and repeated changes, and S3 connects an effect to navigation and casting. The project reports document the other two completed gameplay scenarios and the save/restore workflow. These results evaluate the same implemented system across authoring and play.

Three design findings follow. First, asset compatibility and recipient selection are separate tasks. The stair integration check exercises an additional imported asset after its required material inputs have been assigned. S2 subsequently extends a controller's list from three to seven entries and changes the visible group without showing a new controller implementation. Compatible asset preparation can therefore precede selection of the objects affected by an interaction; support for arbitrary imports is not implied.

Second, a local control value is an input to a composed scene condition. The recovered graph adds and saturates global and local contributions before further mask processing; all four transition interpolators then receive the resulting shared signal. Group membership, per-component values and shared environment parameters consequently need separate representation. The documented save payload includes local mesh records and shared parameters, consistent with that requirement. This explains why retaining only slider values would not describe the full scene condition; it does not establish stable identities after edits or precedence between simultaneous writers.

Third, endpoint acceptance and transition inspection are different checks. S1 supplies an actual intermediate condition, while the stage-2 appearance defect and scan-base correction document cases where an implemented transformation needed further visual work. A representation that preserves the endpoints can still give unsatisfactory intermediate presentation. This finding concerns the graphics workflow; concealing a mismatch with an effect does not improve measured registration accuracy.

The seasonal case demonstrates coordinated transitions between observed conditions. It does not establish metrological change detection: methods such as M3C2 estimate change from repeated three-dimensional surveys, a different objective from producing controllable intermediate renderings [15]. Neither a visually plausible morph nor a functional slider quantifies the displacement, uncertainty or physical trajectory of a surface between acquisitions.

The broader workflow could be investigated for observed changes after fire, flooding or destruction, including the documentation and presentation of damaged heritage in Ukraine. These are prospective applications, not completed experiments. They would require suitable repeated observations and an explicitly justified correspondence; missing surfaces and topology changes may exceed the prepared representation. The earlier burned-looking stump is an illustrated UE appearance, not evidence that a physically burned object was scanned or that such an application has been validated.

The system evaluation combines development-stage tests and demonstrations with supplementary analyses of their records and source implementation. The record-based assessment is author-led; reports overlap and recordings represent selected sessions, even though their full temporal extents were sampled. The supplementary 2026 checks did not repeat Unreal execution, the Blender–FBX–UE round trip or runtime controller and restoration tests. Saved source connections and captured runtime behaviour therefore remain distinct evidence, without a new trace connecting every native asset version to each recording. Rendering observations describe whole-scene operation under recorded settings. Isolated cost or scaling claims would require matched workloads and CPU/GPU traces, for which Unreal Insights provides appropriate facilities [16]; restoration reliability would require repeated comparisons of saved and restored scene values. The demonstrated controls and playable use support the functional conclusions without establishing these stronger quantitative claims.

7. Conclusions

The ODD INN system connects repeated photogrammetric observations to controllable scene transformations. Offline preparation in Blender supplies compatible geometry, deformation data and paired material inputs; the Unreal implementation coordinates displacement, colour, normals and packed material properties through a shared blend mask under local, group and spatial controls. A substantial summer/winter museum campaign supplied selected assets for Odmieniec, where sliders and three spell scenarios connect the prepared states to player interaction. Integration tests, recorded demonstrations and supplementary analyses document intermediate rendered appearance, extension of controlled groups and repeated changes in both directions, together with reported restoration. The design separates asset compatibility from recipient selection and local values from environmental constraints, while the development observations show why intermediate-state inspection complements endpoint checks. The resulting contribution is the implemented capture-to-interaction workflow and its use in a playable seasonal environment. Geometric accuracy, restoration reliability and the execution cost attributable to the transition architecture remain incompletely characterized.