Fix: docs/VIDEO_MODEL.md

[olek-osikowicz]

Hi,

I am proposing two minor fixes to the docs/VIDEO_MODEL.md on onboarding new users to video (world) models.

1. Flashdreams local image tag mismatch

Problem:
The current documentation instructs users to build the base image using the tag flashdreams-base:local:

docker build -t flashdreams-base:local -f docker/Dockerfile .

However, docker/Dockerfile.alpasim expects flashdreams:local as its base image. This causes the subsequent build command to fail because the expected base tag is missing:

docker build -t flashdreams-alpasim:local -f docker/Dockerfile.alpasim .

Fix:
I updated the documentation command to tag the base image as flashdreams:local:

docker build -t flashdreams:local -f docker/Dockerfile .

2. Ensure cache directories existing on host

Problem:

Managed flashdreams container mounts cache directories in the docker-compose.yml deployment like:

  renderer-0:
    networks:
      - microservices_network
    volumes:
      - /home/ubuntu/.cache/huggingface:/root/.cache/huggingface
      - /home/ubuntu/.cache/torch:/root/.cache/torch
      - /home/ubuntu/.cache/flashdreams:/root/.cache/flashdreams

However if they don't exist on host, they might not be created by Docker automatically and crash the deployment.

Fix:
Added an explicit mkdir -p step to ensure the host cache directories exist prior to running the AlpaSim wizard:

mkdir -p ~/.cache/huggingface ~/.cache/torch ~/.cache/flashdreams

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[jatentaki]

Hi Olek, thanks for your contribution! These are all valid changes and I was about to publish a similar fix but got stuck on a separate blocker.

Due to some hiccup, the latest huggingface dataset release (version 26.04), which Alpasim uses by default, does not contain the GT camera frames needed to "seed" OmniDreams. They are available in the older 26.02 release but not in the current defaukl. We hope to get 26.04 fixed up with the missing files in the next couple of days and I prefer that over changing the data source for OmniDreams specifically.

Which .usdz artifacts did you use in your experiments? Unless you forced 26.02 it shouldn't work even with your (otherwise correct) changes. I'd just want to understand your situation before I take further action.

[jatentaki]

(closes: #119)

[olek-osikowicz]

Hi Michał,

Thanks for getting back to me. I also encountered the dataset mismatch issue on my end, but as you noted, it's independent of what this PR addresses.

Changes in this PR address issues in docs w.r.t. Docker build tags and cache directory fix, and doesn't propose changing the default OmniDreams data source.

That said, let me elaborate on the .usdz artifacts and another issue I found with the managed flashdreams pipeline that you might be interested in.

Dataset mismatch

The deployment command from the VIDEO_MODEL.md docs under the Deploy section:

uv run --project src/wizard alpasim_wizard \
  deploy=managed_flashdreams \
  topology=1gpu \
  driver=vavam_video_model \
  +chunking=8frame \
  wizard.log_dir=$PWD/outputs/managed-flashdreams-vavam-run

doesn't specify a scenario artifact so it defaults to clipgt-01d503d4-449b-46fc-8d78-9085e70d3554. This however on resolution it defaults to the newest version 26.04, which is currently currently GT camera frames as you mentioned, and fails shortly after.

So for my experiments I refered to the dataset of version 26.01 and specifically used those scene_ids that are present in 26.01, but not in 26.04, e.g., scenes.scene_ids=['clipgt-02eadd92-02f1-46d8-86fe-a9e338fed0b6'].

Suggested fix:

To avoid similar problems in the future, and improve experiment reproduciability, I would suggest allowing users to pin a dataset version in alpasim_wizard as another Hydra config parameter (e.g., hf_revision=26.01) and documenting that in VIDEO_MODEL.md docs and elsewhere.
This could be addressed in a separate issue/PR though.

Tweaks to the flashdreams-alpasim Dockerfile

Problem

Lastly, I noticed that docker/Dockerfile.alpasim in the flashdreams repository needs a slight modification to work with AlpaSim's managed_flashdreams deployment out of the box.

The Dockerfile currently uses a two stage build:

ARG FLASHDREAMS_BASE_IMAGE=flashdreams:local
FROM ${FLASHDREAMS_BASE_IMAGE} AS wheel-builder
...

FROM ${FLASHDREAMS_BASE_IMAGE}
COPY --from=wheel-builder /opt/flashdreams /opt/flashdreams
ENV VIRTUAL_ENV=/opt/flashdreams
ENV PATH="${VIRTUAL_ENV}/bin:${PATH}"
WORKDIR /app

However, when running the deployment=managed_flashdreams, flashdreams-alpasim rendering container fails on startup with:

renderer-0-1    | error: No `pyproject.toml` found in current directory or any parent directory

Because not all project files (like pyproject.toml) are copied over from wheel-builder, the startup command uv run --no-sync --package flashdreams-omnidreams python -m omnidreams.grpc.server... crashes.

My fix

My current dirty workround is to simply remove multi-stage build steps starting from line 29 to the end.

Once removed and rebuilt, managed_flashdreams works as expected.

I believe this issue belongs in the flashdreams repo, if you can confirm this behavior on your end, I’d be happy to open a PR over there with the cleaner fix.

---

Sorry for the lengthy reply, but I hope my investigation helps shed some light on the onboarding setup from a new user's perspective. I'd be happy to contribute fixes for these as well :)

Olek