We compare the released RealWonder pipeline with a depth-video replacement using the same prepared lamp and persimmon assets, image, prompt, action and camera configuration. Follow the actual saved reconstruction, simulation and condition artifacts through to the generated RGB. All six generated videos on this page already existed; this package required no new model inference.
This is an explanatory visual comparison, not a superiority benchmark. The generators, seeds, samplers, physical sampling grids and foreground composition differ. Neither route has validated physical accuracy here. Plausible geometry does not establish single-image physical initialization, and visible motion does not prove that all simulator facts survived generation.
What the simulator produces—and why the preview resembles the input
Genesis advances 3D physical state → PyTorch3D renders the moved colored reconstruction → the neural generator produces final RGB. These are three distinct operations. The two scenes here use rigid bodies: a box collision proxy for the lamp and mesh bodies for the persimmons. The colored surface samples shown in the preview follow those rigid transforms; they are not independently simulated particles.
The preview retains the prepared foreground colors and background, so an input-like appearance is expected. It is an appearance-preserving point-cloud rendering of simulated motion, not a direct Genesis viewer capture or a finished neural video. This follows the official method’s separate simulation and RGB/flow rendering streams. In this executed wrapper, the native generator uses render RGB plus RAFT-derived warped noise; the separately saved geometry flow is diagnostic.
Raw Genesis viewer recording: unavailable
The saved runs used debug=false, so the native debug camera was not created. Stage 06 now provides CPU replays of the saved body poses and transported colored points. These diagnostic views are labeled separately from the saved source-camera RGB; they are not native simulator screenshots. No new simulation was run.
The prepared object meshes, point surfaces, background, camera and reference image have identical bytes across the selected original and bridge runs. Relevant physics/action and camera-crop settings agree. The original output uses separately executed simulation renders; its full rigid-state history was not saved, so exact trajectory identity is not established.
Contract
A · Original RealWonder
B · Depth-video replacement
Generator
Released distilled AR I2V-Flow student
Released Wan2.1-VACE-1.3B, reference + depth
Motion input
Simulation RGB → VAE, plus RAFT-derived warped noise
Same-camera positive Z → grayscale RGB condition
Output
81 frames, 832×480, 50 Hz
25 frames, 832×480, 16 Hz
Seeds
Primary 2026092501; existing alternative 2026092502
2026091101
Rendering
Native full prepared point surfaces, foreground overlay
Same full prepared point surfaces, nearest-Z foreground/background composition
Initialization privilege
Prepared reconstruction, assigned physical properties and externally simulated future motion. This is not an automatically initialized image-only forecast.
The primary native seed was selected by lowest recorded seed before visual inspection. Both existing alternatives are retained below. The OBJ meshes shown in 3D are full meshes; the historical image renderer uses all prepared surface points, not sparse project carriers. “Full asset” does not guarantee unseen texture coverage.
Prepared source · 01
Lamp
Same source assets / different video generators
01 · Original inputActual original 512×512 image. Both generators receive the same resized/cropped image shown next.
02 · Reference / extractionSaved extraction masks over the actual 832×480 reference. Colors identify objects; these are not new segmentations.Open unoverlaid generator reference
03 · Scene depthCamera-Z from the completed scene renderer, in prepared units. This is not the original monocular-estimator depth output.
Unavailable intermediate
A standalone original monocular-depth prediction was not present in the bound prepared assets. It has not been fabricated or recomputed.
04 · Full reconstructed geometry4,026 vertices · 8,048 triangles · 1 watertight mesh. Equal axes; novel diagnostic viewpoints. Neutral colors are for display, not recovered material properties.Rotate the actual 3D mesh
The static two-view image remains available if browser WebGL is unavailable.
05 · Simulation setupSaved initial poses + saved center paths from the bridge simulation. This is a diagnostic plot, not a Genesis viewer capture. The finite plane patch illustrates the source’s infinite plane rule; it is not a new simulation or a recovered camera.
One rigid lamp. A constant +X force of 1 is applied each step; gravity is −1 in the prepared simulation units. The collision body is a box; the apparent water is background imagery, not a water simulation.
Source-camera alignment and background preparation
Actual t=0 source-camera rendering, before generation.Existing prepared background. It is a reconstruction/inpainting asset, not an observed clean background or a newly generated target.
Camera: identical saved K/R/T. The 512×512 source render is scaled uniformly by 832/512, then cropped vertically at y=200 to 832×480. No camera search or crop rescue was performed.
06 · Shared physical-motion and rendering stages
3D body motion → material transport → camera-view preview
These three views expose the motion-to-render chain before the generator-specific conditions. Use the shared controls to inspect the same saved time in all three views.
Lamp box collision proxy at recorded poses; no texture or water dynamics. CPU replay of saved bridge states; fixed diagnostic camera and equal spatial scale. This is not a native Genesis screen recording.
All 19,394 prepared foreground points, with saved colors, moved by the executed pose-to-point transform. The 3D display omits the background to expose the object surfaces. These points are appearance carriers, not independent simulated particles.
25 frames at 16 Hz; t=0–1.5s. Saved PyTorch3D rendering of these same transported points, with the prepared background and source camera. The motion condition for VACE is depth at stage 07, not this explanatory RGB preview.
No new simulation or model inference. Body placement follows the recorded solver poses; point transport follows the recorded initial-render transform, preserving the source implementation’s alignment convention. The first two diagnostic views do not replace the source camera or repair its crop. Exact replay bindings and numerical checks.
Preserved original RealWonder preview and recording differences
81 frames at 50 Hz; source times 0.02–1.62s. The first frame is post-step. The separate PyTorch3D renderer transports saved foreground colors over a cached background. This preview is the actual native RGB condition; the neural generated output is shown below.
Both routes share reconstruction, action and camera settings, but the historical render recordings differ: this native preview has 81 frames at 50 Hz and foreground overlay; the linked replay above uses the bridge’s 25 saved states at 16 Hz and nearest-Z composition. The original complete pose history is unavailable. Moving this evidence into the shared section does not claim identical simulation frames across runs.
07–08 · Framework-specific conditions and generation
Display of the saved displacement tensor: 80×2×240×416. Hue gives direction; brightness gives magnitude in this scene’s fixed range. Units: pixels per 20ms at the 416×240 RAFT grid.
Display only: channels 0–2 of the saved 81×60×104×32 tensor, clip(n/4+0.5). This is before temporal sampling and random mixing; it is not RGB motion footage.
Native code encodes simulation RGB to [1,21,16,60,104]. NoiseWarper.process(input_flow=False) computes RAFT from simulation RGB. load_noise samples 81→21 frames, applies degradation 0.5 and splits 16+16 channels. The separately saved geometry flow is diagnostic, not this conditioner.
Not persisted
The exact post-mixing runtime noise and simulation VAE latent arrays were not saved. The displayed upstream inputs, executed shapes and code path are bound. No replacement latent has been invented. Mask drop-in was −1, so reconstruction masks were not injected as a generator condition.
Viewing encode of the exact consumed 25×480×832×3 array. Near is bright; far is dark. Per-frame valid inverse-Z min/max normalization, identical RGB channels. Raw camera-Z and validity remain bound in the manifest.
The native VACE processor receives depth [3,25,480,832] plus reference [3,1,480,832]. The completed run verified an exact input pixel round-trip. Per-frame inverse-depth normalization discards absolute scale and can change temporal contrast. Depth is never sent into RealWonder’s flow-noise slot.
The reference is not a hard first-output-frame clamp. Background synthesis, material drift, surface holes and upstream clipping remain possible. This replaces the video condition and generator, not just one tensor within a matched backbone.
The slider pauses the two final outputs at their nearest recorded source-bound times and reports both. Playback remains at each file’s original cadence; no stretching, frame interpolation or latent repetition.
Observed motion and visible limits
Both saved native sequences show the lamp moving right while retaining its box, base and floral pattern. The primary native output reaches the right edge near the end. The depth output also moves right but redraws the paper surface and water, brightens the light and loses the floral pattern. This is visible trend transfer with appearance differences, not a measured motion-fidelity ranking.
The bridge source lamp stays inside the image, but neither output is numerically qualified for center, orientation, velocity or material transport. Simulated rigid-plane motion is not a validated model of a floating lantern.
Initial, 0.75s and 1.5s target times, using the nearest native frame. Whole frames retained. Labels expose actual timestamps; these are illustrations, not a re-scored benchmark.
All saved output frames, second native seed, and exact scene records
01 · Original inputActual original 512×512 image. Both generators receive the same resized/cropped image shown next.
02 · Reference / extractionSaved extraction masks over the actual 832×480 reference. Colors identify objects; these are not new segmentations.Open unoverlaid generator reference
03 · Scene depthCamera-Z from the completed scene renderer, in prepared units. This is not the original monocular-estimator depth output.
Unavailable intermediate
A standalone original monocular-depth prediction was not present in the bound prepared assets. It has not been fabricated or recomputed.
04 · Full reconstructed geometry12,374 vertices · 24,840 triangles · 3 watertight meshes. Equal axes; novel diagnostic viewpoints. Neutral colors are for display, not recovered material properties.Rotate the actual 3D mesh
The static two-view image remains available if browser WebGL is unavailable.
05 · Simulation setupSaved initial poses + saved center paths from the bridge simulation. This is a diagnostic plot, not a Genesis viewer capture. The finite plane patch illustrates the source’s infinite plane rule; it is not a new simulation or a recovered camera.
Three rigid objects. Object 0 receives +X force 100 and object 1 −X force 100 for source steps 0–5; the bottom object has no prescribed force. Gravity is −9.8. The initial top/middle centers have source-defined +0.025/+0.015 Z offsets.
Source-camera alignment and background preparation
Actual t=0 source-camera rendering, before generation.Existing prepared background. It is a reconstruction/inpainting asset, not an observed clean background or a newly generated target.
Camera: identical saved K/R/T. The 512×512 source render is scaled uniformly by 832/512, then cropped vertically at y=165 to 832×480. No camera search or crop rescue was performed.
06 · Shared physical-motion and rendering stages
3D body motion → material transport → camera-view preview
These three views expose the motion-to-render chain before the generator-specific conditions. Use the shared controls to inspect the same saved time in all three views.
Full rigid source meshes at recorded poses; neutral colors. Internal solver convex decomposition is not reproduced. CPU replay of saved bridge states; fixed diagnostic camera and equal spatial scale. This is not a native Genesis screen recording.
All 37,111 prepared foreground points, with saved colors, moved by the executed pose-to-point transform. The 3D display omits the background to expose the object surfaces. These points are appearance carriers, not independent simulated particles.
25 frames at 16 Hz; t=0–1.5s. Saved PyTorch3D rendering of these same transported points, with the prepared background and source camera. The motion condition for VACE is depth at stage 07, not this explanatory RGB preview.
No new simulation or model inference. Body placement follows the recorded solver poses; point transport follows the recorded initial-render transform, preserving the source implementation’s alignment convention. The first two diagnostic views do not replace the source camera or repair its crop. Exact replay bindings and numerical checks.
Preserved original RealWonder preview and recording differences
81 frames at 50 Hz; source times 0.01–1.61s. The first frame is post-step. The separate PyTorch3D renderer transports saved foreground colors over a cached background. This preview is the actual native RGB condition; the neural generated output is shown below.
Both routes share reconstruction, action and camera settings, but the historical render recordings differ: this native preview has 81 frames at 50 Hz and foreground overlay; the linked replay above uses the bridge’s 25 saved states at 16 Hz and nearest-Z composition. The original complete pose history is unavailable. Moving this evidence into the shared section does not claim identical simulation frames across runs.
07–08 · Framework-specific conditions and generation
Display of the saved displacement tensor: 80×2×240×416. Hue gives direction; brightness gives magnitude in this scene’s fixed range. Units: pixels per 20ms at the 416×240 RAFT grid.
Display only: channels 0–2 of the saved 81×60×104×32 tensor, clip(n/4+0.5). This is before temporal sampling and random mixing; it is not RGB motion footage.
Native code encodes simulation RGB to [1,21,16,60,104]. NoiseWarper.process(input_flow=False) computes RAFT from simulation RGB. load_noise samples 81→21 frames, applies degradation 0.5 and splits 16+16 channels. The separately saved geometry flow is diagnostic, not this conditioner.
Not persisted
The exact post-mixing runtime noise and simulation VAE latent arrays were not saved. The displayed upstream inputs, executed shapes and code path are bound. No replacement latent has been invented. Mask drop-in was −1, so reconstruction masks were not injected as a generator condition.
Viewing encode of the exact consumed 25×480×832×3 array. Near is bright; far is dark. Per-frame valid inverse-Z min/max normalization, identical RGB channels. Raw camera-Z and validity remain bound in the manifest.
The native VACE processor receives depth [3,25,480,832] plus reference [3,1,480,832]. The completed run verified an exact input pixel round-trip. Per-frame inverse-depth normalization discards absolute scale and can change temporal contrast. Depth is never sent into RealWonder’s flow-noise slot.
The reference is not a hard first-output-frame clamp. Background synthesis, material drift, surface holes and upstream clipping remain possible. This replaces the video condition and generator, not just one tensor within a matched backbone.
The slider pauses the two final outputs at their nearest recorded source-bound times and reports both. Playback remains at each file’s original cadence; no stretching, frame interpolation or latent repetition.
Observed motion and visible limits
Both routes show the upper objects separating and falling toward opposite sides, followed by overlap near the lower boundary. Generated leaves, highlights, fruit contours and background differ. The prepared crop already truncates the bottom fruit at the first frame; later cropping and overlap prevent complete-object and contact adjudication. The original route also shows strong lower-edge truncation.
Initial, 0.75s and 1.5s target times, using the nearest native frame. Whole frames retained. Labels expose actual timestamps; these are illustrations, not a re-scored benchmark.
All saved output frames, second native seed, and exact scene records
PNG files contain real images, full geometry or exact saved-array visualizations. Labels and diagnostic viewpoints are newly composed. None is an AI-generated reconstruction or a fabricated scientific observation.
Figure 1 · Lamp: input → full 3D geometry → simulator/control → both generated outputs.Figure 2 · Plausible geometry versus unverified support, material and physical state. No silhouette-improvement ablation was performed.Figure 3 · Fixed-time persimmon limitations, keeping source crop and generated appearance changes distinct.Figure 4 · Actual native conditions, tensor shapes and physical-time differences.
An executable interface exists. Prepared reconstruction → actual simulation → video conditions → generated RGB is demonstrated in both routes without our learned dynamics module.
Some motion trends transfer. Rightward lamp motion and persimmon separation/fall are visible. Exact simulator trajectory and material correspondence are not qualified.
Geometry is available; physical identification remains open. Full, watertight object meshes do not tell us the correct support/fixation, density, friction or initial physical state. These are configured in this demo. The examples do not rank the relative difficulty of reconstruction and initialization across scenes.
The generator remains an uncertain interface. Appearance drift, crop, overlap, missing surface texture and changing background remain. Hidden contact and complete-object integrity cannot be certified from these clips.
Research implication: our learned dynamics module can be deprioritized as a prerequisite for a prepared-scene condition-to-RGB demonstration. This is not evidence to remove it from the long-term research objective.
No validated physical correctness; no depth-over-flow superiority; no proof of full simulator adherence; no solved single-image initialization; no scientific head-to-head between our old learned dynamics and the simulator.
Bindings, missingness and local use
All historical videos are preserved. Six original-pipeline MP4s have losslessly remuxed fast-start viewing copies; their decoded pixels, frame counts and timestamps are identical. Other media remains byte-identical. New work consists of a static page, full-mesh views, saved-state setup views, control visualizations, frame sheets and presentation figures. No new simulation, model inference, GPU query or training was needed. Geometry views use equal spatial scaling in prepared reconstruction units; their viewpoints and flat display colors are explicitly diagnostic.
Native RealWonder
Released student checkpoint: Realwonder-Distilled-AR-I2V-Flow/.../step=000800.pt, generator state. Lamp step list [800,500,250]; persimmon [300,200,100]. BF16 generator/text/streaming VAE; FP32 initial-image VAE/CLIP. Local attention21, sink1, frame-per-block3, mask drop-in−1, degradation0.5. Exact absolute paths are in the bindings.
Depth bridge
Wan2.1-VACE-1.3B, 2,153,972,032 parameters including control modules. FP32 stored parameters / BF16 autocast. Reference + depth; UniPC50, shift16, CFG5. No new weights or adapters.
Unavailable
Standalone original monocular depth; exact native post-mix noise and simulation latents; the old native complete rigid-state arrays; independent physical ground truth. These gaps do not erase the saved conditions and outputs, but limit claims.
Publication
This page is published in the dedicated Hugging Face Static Space TEric-22612/realwonder-pipeline-comparison. All-video local and live playback checks are recorded separately below. Local viewing works without a backend; interactive 3D uses bundled Plotly with a PNG fallback.
Upload the contents of review/ to a Static Space with sdk: static and app_file: index.html. For local HTTP viewing, use the included serve.py with MP4 byte-range support. No external assets, analytics, forms or model calls are embedded.
