MiniMax H3 -> LTX Phase A - Gemma Conditioning + Destroy

The finishing pass in the H3 Shotboard is "render H3, then upscale with LTX" - and LTX's text conditioning needs a big language model. The Gemma Conditioning + Destroy node is Phase A of that handoff: it encodes your positive and negative text with Gemma 3 12B plus the LTX text projection, materializes the result on the CPU, and then destroys the Gemma model to get its VRAM back before the heavy work begins. "Destroy" is in the display name and it's not a figure of speech.

Why the destroy matters

MiniMax H3 already fills most of a 12GB card. Adding Gemma 3 12B on top - even an fp8 quant - is the difference between an upscale pass that runs and a workflow that OOMs the moment you queue it. The pack's answer is a phased memory contract: encode the text early, move the conditioning out of VRAM, and free the encoder immediately. The "phase A" / "phase B" naming comes from splitting the LTX handoff into conditioning (this node) and the denoise stack (a separate node), with a memory barrier between them.

How it works

You feed it trigger_frames (the decoded native H3 frames - it uses them only to validate and to report the count, not to condition on), plus positive_text and negative_text. The node loads Gemma via DualCLIPLoader with the ltxv type, encodes both prompts with a stock CLIPTextEncode, force-materializes the conditioning tensors on the CPU, and then - in a finally block, so it happens even on failure - deletes the encoder and clip references and runs the memory release. The conditioning survives on the CPU; the 12B model does not.

The two enum inputs, text_encoder_name and text_projection_name, are populated from your installed files (Gemma 3 12B fp8 and the LTX text projection - ltx-2.3_text_projection_bf16.safetensors are the expected defaults). text_encoder_device lets you force the encode to cpu if you want zero GPU pressure on the text side.

Outputs

positive and negative conditioning, ready for the LTX denoise/sampling stage, and a report string confirming the phase completed and Gemma was destroyed. If you see the report say "Gemma/projection destroyed=no", something in the release path failed and you should be suspicious of your next render.

Installing it

Part of IAMCCS-nodes (Manager, search "IAMCCS", or git clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart). Beyond that you need the LTX model files - the Gemma 3 12B fp8 text encoder, the LTX text projection, the LTX diffusion model, and the LTX video/audio VAEs. Those are real downloads measured in tens of gigabytes; budget accordingly.

Gotchas

This node will raise if trigger_frames isn't a valid 4D image batch with at least one frame - it's a hard validation gate at the top of the H3→LTX handoff. And the classic "the preview worked but the upscale OOM'd" problem is usually this: the phase-A node encoded text but the Gemma weights leaked into the sampling stage. Watch for the destroy confirmation in the report, and keep this node on the CPU-safe device option if you're under 16GB.