MIDI-3D Texture

So you ran MIDI-3D and got a scene of grey meshes. MIDI-3D Texture is what turns them into something that looks like it has a material and a light source. It takes your generated scene plus the original per-instance images, and gives every mesh a real texture - multi-view consistent, meaning the colors agree when you spin the object around instead of looking like two photos stapled together.

This is the most expensive node in the pack, bar none. It's not one diffusion run; it's one per mesh, on top of the 14GB texturing stack, plus mesh processing and a 4096×4096 UV projection for every object. A two-object scene can take a long time on a mid-range card. If you're impatient, this node will teach you patience.

The inputs

• texture_models - the MIDI3D_TEXTURE_MODELS bundle from MIDI-3D Load Texture Models.
• scene - the MIDI3D_SCENE from MIDI-3D Process.
• preprocessed - the MIDI3D_DATA from the preprocess node. The texture pass reuses the per-instance RGB crops and masks as the reference appearance for each object.
• seed - default 42, -1 for random. Locks in the multi-view generation.
• num_inference_steps - default 35 (range 1–100). More steps = more consistent views, slower per object.
• guidance_scale - default 3 (range 0–20). This one is lower than the geometry pass because MV-Adapter leans on the reference image more than on prompt guidance. Don't copy your geometry settings here; 3–5 is the sane band.

How it works

For each mesh it does a little production line:

1. Exports the mesh, preprocesses it, and renders it from six camera angles (position + normal maps) with the CUDA rasterizer.
2. Feeds those renders plus the object's reference image into MV-Adapter, which generates a 6-view image grid of what the textured object should look like.
3. Feeds the views into the texture pipeline, which upscales, inpaints seams, and projects color onto a 4096×4096 UV map per mesh.

The output is a MIDI3D_SCENE again - textured_scene - same scene type, but now each mesh carries texture. It wires into Scene to Trimesh the same way the untextured version does, so the export half of your workflow doesn't care whether you textured or not.

Where it actually bites

• Overlapping instance views. The texturing reuses the per-instance crops, so if your objects occlude each other heavily in the source image, the back object's reference is partly hidden and its texture comes out wrong. The padding option on the preprocess node (do_padding) exists partly for this. Re-run preprocess with padding if rear objects look like they got half a texture.
• It's sequential and slow. One mesh at a time, full SDXL diffusion each. There's no batch knob. Budget for it, or texture a smaller subset.
• Seam artifacts. The uv_unwarp=False / inpaint settings in the source try to keep seams hidden, but complex meshes will show projection seams up close. This is research-grade texturing, not a game asset pipeline.

The honest framing: this node is where the pack's WIP status shows most. It works - the pack ships a complete texture workflow, and it produces genuinely multi-view-consistent results - but it demands a big GPU, a patient temperament, and clean per-instance inputs. If you have all three, it's the difference between a grey blob and a usable scene. If you don't, generate without textures first and see whether you even need them.