Diffusers MV Model Makeup

This is the assembly node - the one that takes a plain SDXL pipeline and turns it into a multi-view generator. On its own the pipeline loader gives you vanilla SDXL. Model Makeup is where the actual MV-Adapter weights get attached, along with the scheduler and VAE, so that the sampler downstream produces a consistent set of views instead of one image. If MV-Adapter has a "load the special sauce" step, this is it.

Everything about "makeup" is metaphor: you're dressing up a base model with the parts that make it do the multi-view trick.

How it works

MV-Adapter is an adapter, not a checkpoint - it patches attention behavior into a frozen SDXL so the model can generate several camera angles that share geometry and lighting. This node is where that patch gets applied. It gathers three things you loaded separately (the base pipeline, a scheduler, a VAE), loads the adapter weights on top, and emits one fully-configured pipeline that the Diffusers MV Sampler can run.

The inputs that matter

Three of the required inputs are just plumbing - pipeline (from a pipeline loader), scheduler (from the Scheduler Loader), and autoencoder (from a VAE loader). The ones you actually decide on:

• adapter_name (enum) - the critical setting. This picks which MV-Adapter weight to load, and it has to match what you're doing. The choices are mvadapter_t2mv_sdxl.safetensors (text-to-multiview, the default), mvadapter_i2mv_sdxl.safetensors (image-to-multiview), mvadapter_i2mv_sdxl_beta.safetensors (the beta i2mv model, better at partial view sets), plus the two SD 2.1 variants. Text prompt only? Use a t2mv. Driving from a reference image? Use an i2mv. Get this wrong and the results won't make sense.
• num_views (default 6) - keep it aligned with the sampler's num_views.
• enable_vae_slicing (optional, default true) - leave it on. The README explicitly recommends this to keep SDXL's memory footprint down, and it costs you nothing.
• adapter_path (default huanngzh/mv-adapter) - the Hugging Face repo the weights come from. You basically never touch this.

The output is a single PIPELINE - the dressed-up model, which goes straight into the sampler (or through a LoRA/ControlNet loader first).

A note on the VAE input

Feed this the right VAE and your VRAM headache eases. The README's advice is to use madebyollin/sdxl-vae-fp16-fix - the community-standard rescaled SDXL VAE that stops the original from producing black images and NaNs in fp16. It's the reason your SDXL decode stays in half precision instead of forcing an expensive fp32 pass. The Diffusers MV Vae Loader defaults to exactly this repo, so if you used that loader you're already set.

Installing the pack

ComfyUI Manager, search ComfyUI-MVAdapter, install, restart. Or manually: cd ComfyUI/custom_nodes && git clone https://github.com/huanngzh/ComfyUI-MVAdapter, then pip install -r requirements.txt, then restart. The adapter weights download from Hugging Face on first run.

Where people get burned

The adapter_name mismatch is the number-one trap - running a t2mv adapter while wiring in a reference image, or vice versa. Match the adapter to your intent.

Second, memory. This is where the two VRAM levers live (VAE slicing here, plus the fp16 VAE choice upstream), and even with both, SDXL as a base still wants around 13–14GB. If you're using the LDM pipeline path with the fp16 VAE, the README adds one more: set upcast_fp32 to False on the LDM VAE loader, or you throw away the fp16 saving.

Third - for the beta image-to-multiview model specifically - the README notes that num_views is ignored when you drive views through a View Selector. So if you're using the beta model with view selection and wondering why num_views seems to do nothing, that's expected, not broken.