Search Every World You Generate with Atlas

The Short Answer

Atlas outputs images and video alongside 3D point clouds, Gaussian splats and depth maps. Mixpeek indexes the first two by their content: send each render to a bucket, point a collection at that bucket with the multimodal extractor, and query a retriever in plain language. The 3D artifacts are not indexable by content today, so keep them as files and reach them through the render that IS indexed. Three calls, and nothing is downloaded or re-encoded on the way in.

Why a generated world is harder to find than a generated clip

A text-to-video model hands back one artifact and you search it. A world model hands back a scene, and the scene is not a thing you can watch. What you can watch is a camera path through it, which is one of many, chosen by whoever ran the job.

That is the retrieval problem in one sentence. The world holds more than any single render shows, so a search over renders finds what somebody happened to point the camera at and misses everything they did not. Two paths through the same reconstruction produce two files that look unrelated and share every underlying voxel.

Atlas makes this concrete. Per its announcement it reconstructs a scene from one to dozens of input images and renders up to a minute of video at 1440p along a camera path you hand-design up front, rather than steering live. So the render is a deliberate excerpt of the world, and the world itself is a point cloud, a set of Gaussian splats and depth maps.

The practical consequence: index the renders, and treat the render as the handle on the world rather than the whole of it.

What Atlas emits, and what is searchable by content

Artifact

Searchable by content in Mixpeek

How to reach it

Video, up to 1 min at 1440p	Yes	multimodal extractor: frames, audio, on-screen text
Images	Yes	image extractor, or the multimodal extractor alongside video
Depth maps	As images only	They index as pixels, which finds shapes and not distances
3D point clouds	No	Store the file, put its URI in payload beside a render
Gaussian splats	No	Same: reachable through the render, not by content

The honest line is the third column. Mixpeek's extractors take image, video, audio, pdf, text and string, which is what GET /v1/discovery/extractors reports, and none of them reads a splat or a point cloud. Anyone telling you otherwise is describing a roadmap.

Depth maps deserve the caveat rather than a yes. They are PNGs, so they ingest, and an embedding over them matches on silhouette and layout. It does not match on depth as a quantity, because the model reads brightness and not metres.

The three calls

# 1. bucket: land every render Atlas produces
POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"video","type":"video","data":"https://your-storage/atlas/scene-0417-path-a.mp4"}]}

# 2. collection: multimodal extraction runs on arrival
POST /v1/collections
{"collection_name":"worlds",
 "source":{"type":"bucket","bucket_ids":["{bucket_identifier}"]},
 "feature_extractor":{"feature_extractor_name":"multimodal_extractor","version":"v1"}}

# 3. retriever: search every world you generated
POST /v1/retrievers/{retriever_id}/execute
{"inputs":{"query":"interior courtyard at dusk, camera pushing through the arch"}}

data takes an HTTP, HTTPS or S3 URL and Mixpeek fetches it, so the render never passes through your machine. Atlas is in early access with select partners and its announcement documents no output URL or API, so put the render wherever you already keep files and point data at that. The flow does not care which storage it is.

Keeping the world attached to the render

One world produces many renders, and a search that returns a render is only useful if you can get back to the scene it came from. Blob metadata is promoted onto the object at ingest and is filterable afterwards, so it is the place to carry the join:

POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"video","type":"video",
           "data":"https://your-storage/atlas/scene-0417-path-a.mp4",
           "metadata":{"scene_id":"scene-0417",
                       "camera_path":"path-a",
                       "splat_uri":"s3://worlds/scene-0417/splat.ply",
                       "point_cloud_uri":"s3://worlds/scene-0417/cloud.ply",
                       "source_images":9}}]}

Now a plain-language query finds the moment, and scene_id gives you every other render of the same world plus the URIs of the 3D artifacts nobody can search by content. That is the pattern: semantic match on what is watchable, exact filter on what is not.

Render more than one path per scene if search coverage matters. Two or three passes at different heights cost a little render time and are the difference between a world being findable and a world being findable from one angle.

Frequently Asked Questions

Can Mixpeek search a Gaussian splat or a point cloud directly?

No. GET /v1/discovery/extractors reports six input types, image, video, audio, pdf, text and string, and no shipping extractor reads a splat, a point cloud or a mesh. The working pattern is to index the renders and carry the 3D file's URI in payload, so a semantic hit on the video hands you the scene. If your retrieval genuinely needs geometry rather than appearance, that is a different index and this is not it.

How do I search a world nobody has rendered from the right angle?

You cannot, and it is worth being blunt about it because it is the failure people hit second. Retrieval sees the renders you produced, so a courtyard that no camera path passed through is absent from the index no matter how well the reconstruction captured it. The fix is coverage at generation time: render two or three paths per scene rather than one, and treat that as part of the ingestion cost.

Are depth maps useful in the index?

Marginally, and not for what people expect. A depth map is a PNG, so it ingests as an image and its embedding matches on silhouette and spatial layout. It does not let you query by distance, because the extractor reads brightness values and has no idea they encode metres. Index them if you want "scenes shaped like this one"; do not index them expecting "objects within two metres of the camera".

Does this work for Marble output too?

Yes, and for the same reason it works for Atlas. Marble uses the same Gaussian splat representation, and the split is identical: the renders you export are indexable by content, the splat is a file you reference. Nothing in the three calls is Atlas-specific, which is the point of putting the vendor's URL in data rather than building a vendor integration.

What does a query actually match on for a rendered world?

The features the extractor produced from the rendered frames: segment-level and frame-level representations plus any speech and on-screen text. It does not match the prompt, the scene id or the filename unless you attached those as metadata, and metadata is a filter rather than a semantic match. That is why "interior courtyard at dusk" works on a file called scene-0417-path-a.mp4.

Is one minute of 1440p video expensive to index?

Extraction is the dominant cost and it is paid once per object, so the question is how many renders you produce rather than how long each one is. A world generating three camera paths costs three extractions. The cost to watch is a back catalogue of near-identical passes over the same scene, which is the case for deduplicating before you extract.

Related

Search everything you generate on fal for the same three calls against a text-to-video model

Best video deduplication tools for collapsing near-identical camera passes before you pay to extract them twice

Video scene segmentation for how a render is cut into the units a query matches

Buckets, objects and blobs for the full ingestion contract