ATAS, short for Any Time, Any Space, is a framework for keeping a reusable world behind a multi-shot film. Its question is more specific than making one clip longer: can the camera return to the same room later, or show an earlier event from another angle, while preserving the relevant spatial and temporal evidence?
That makes it relevant to MiniMax H3 creators building scenes across cuts. It is not a new H3 checkpoint or a promise that any generated room will remain perfectly consistent. This explanation follows the authors' repository, world-state design notes, and research paper, submitted October 14, 2026 and reviewed here October 21. We have not installed ATAS or reproduced its evaluations.
Scene memory and event memory answer different questions
Imagine a bookstore with a blue entrance, a round reading table, and a customer putting a parcel down. A later shot looks back toward the door. Scene memory supplies evidence about the bookstore's static structure. An alternate view of the parcel being placed also needs the event and its time interval. Remembering the room alone cannot specify where the moving parcel was at that moment.
ATAS separates those responsibilities. Its persistent state combines registered static geometry with time-indexed dynamic observations. Before generation, a planner queries relevant evidence and renders context for the requested camera. After generation, the new clip goes through reconstruction, registration, and checks before it can change the world state.
The paper reports improvements across four video generators. Those are author evaluations of the framework. They do not show that every public installation has a ready-made connector for every evaluated backbone, or that every arbitrary screenplay will preserve its geometry.
What actually gets stored?
The design notes describe three layers. An observation holds frame-level evidence, including RGB, depth, camera information, dynamic masks, and a manifest. Scene memory accumulates accepted static points in the scene's shared frame. Event memory retains dynamic evidence associated with a particular event and source interval.
Moving subjects are not fused into the static room as permanent furniture. Existing scene points are preserved rather than continually averaged with each new generation. Coordinates derive from the first observation's reconstruction units; they are not certified measurements in metres. This is useful conditioning evidence, rather than a guaranteed dimensionally accurate CAD model.
The first accepted observation matters because later shots inherit its coordinate frame. The system checks that observation and may reconstruct it again against an anchor. If validation fails, a clip can still be delivered as film without becoming trusted world evidence. That distinction explains why a completed MP4 and a successful memory update are separate outcomes.
Installation has a client and a GPU service
The repository's installation instructions require Python 3.12. The client needs ffmpeg and can run without a GPU. The separate geometry service needs an NVIDIA GPU with roughly twenty gigabytes of free memory, according to the authors. That figure describes the geometry service; it is not a total budget for a local H3 generator plus every other component.
The geometry environment configures its Python executable, model root, and GPU IDs. The model root contains Pi3X and SAM3 assets. The supplied startup script exposes a readiness check at /readyz. Validate that service before diagnosing a failed film run as a video-model problem.
The client example configuration currently defaults video generation to Wan 3.0 through DashScope. Planning, visual review, and image generation use separately configured language and image services. An H3 research result does not mean changing one environment variable produces a supported H3 deployment. Inspect the actual provider code and authentication contract before choosing that backbone.
Begin with a bounded planning run
The repository includes bookstore, clockshop, and record examples. Its documented bookstore command is:
atas run --screenplay examples/bookstore/screenplay.txt --characters examples/bookstore/characters.json --story-id bookstore
For an initial review, add the documented --plan-only option and inspect the planned shots before requesting video generation. The repository also exposes --max-shots N, --output DIR, and a --memory none option for runs without world state. Planning can still involve configured external services; do not assume a planning flag proves a zero-cost run.
A useful test screenplay explicitly names one location, one repeated object, and an event whose timing matters. For example, establish the table and door, show the parcel being placed, then request a reverse view of that event. Review whether the plan identifies the same scene and event interval before committing to a larger film. This is a proposed evaluation sequence, not a reproduced tutorial result.
Resume and inspect delivery separately from memory
The README says rerunning the same command resumes without repeating paid generations. Outputs live under the run and story directories and include final.mp4, a per-shot manifest.json, and report.md. Preserve those records together. They help distinguish a delivered shot, a repaired shot, and evidence admitted to memory.
The design also checks that a candidate belongs to the requested scene and descends from the current world version. A stale candidate must be registered against the newer state before publication. This is why integration requires persistent project state and version handling, rather than a single stateless video request.
When reviewing a result, inspect the final edit and its underlying shot records. A visually acceptable clip may have failed registration; an admitted geometric observation may still need editorial review for dialogue, character, or pacing. Neither result alone certifies the whole film.
Where ATAS fits in an H3 workflow
Use Continuum-style continuation when the central need is extending adjacent action through latent overlap. Explore ATAS when the problem is revisiting places and events across nonconsecutive shots. A Blender previs workflow instead starts with authored structural input. These approaches answer related production needs but do not share the same stored state or installation contract.
H3Vid does not currently run ATAS. A hosted implementation would need a geometry worker, durable world versions, planning and review budgets, provider orchestration, and final film delivery. The repository uses MIT for its own code while retaining third-party license files; each model and external service still has its own terms. Start by auditing one small story's plan and artifacts, then decide whether the additional state improves your actual production problem.