八方向序列拆分 / 8-Direction Sprite Split

Game-dev pipelines have a hole in them. You can generate an 8-direction character with an image model, animate it into a walking loop with a video model, matte it with Lucida - and then you stare at a video where every frame is a sprite sheet containing all eight directions, and there's no built-in node that splits it into eight clean, aligned animation strips. That's the hole 八方向序列拆分 / 8-Direction Sprite Split fills. It takes your sequence of sprite-sheet frames, cuts each into its eight directions, and outputs dir_1 through dir_8 as RGBA IMAGE sequences plus an info string with the numbers you actually need for a game engine.

The author's intended pipeline is worth internalizing because it's a great map of what's already solved: character image → 8-direction stills (GPTimage2), stills → loop video (Seedance first/last frame), video → frames (native "Get Video Components" for VIDEO→IMAGE, or VHS Load Video from a file), frame-rate drop (VHS "Select Every Nth Image"), matting (Lucida), then this node, then SaveImage (4-channel inputs save as transparent PNG) or VHS Video Combine with format=video/webm + pix_fmt=yuva420p for transparent webm.

The inputs that actually matter

• images - your frames, each a sprite sheet.
• grid_cols / grid_rows / empty_cells - the layout. The classic 3×3 grid with an empty middle is empty_cells="4" (row-major, 0-indexed). direction_names defaults to SW,S,SE,W,E,NW,N,NE for a sheet where the top row faces the viewer.
• bg_mode - where transparency comes from, and this decides your output quality. 已带透明通道 (already transparent, recommended) uses an upstream matting node's alpha via the optional masks input - the README measured it gnawing 35% less of your subject than the color-threshold route. 白底转透明 (white-to-transparent) is fast color thresholding but estimates alpha by "how far from white", so white clothes get eaten. 不处理 outputs opaque but still crops by character extent.
• edge_shrink / decontaminate - the white-halo fighters. Edge pixels on white backgrounds are white-contaminated; edge_shrink clips that fringe (0.15–0.25 with model alpha, 0.35+ with threshold alpha; the README shows white-edge strength dropping 0.048 → 0.016 as you go 0→0.2→0.5). decontaminate back-solves the true foreground color from observed = fg×a + white×(1−a) - it helps only ~3% alone, so pair them.
• expand_beyond_cell - keep this on. Off, the node cuts strictly at grid lines and feet/capes/staffs get chopped. On, the grid only decides which direction a cell belongs to and the extent comes from the character's connected region.
• align_mode / anchor_type / align_scope - the "switch direction without the character jumping" feature. Default is foot-center anchoring, per-frame nailed down. Why foot-center and not bbox center? Capes and staffs drag the bounding box sideways, but they don't reach the feet - the bottom-band centroid is where the character actually stands. Measured result: per-frame alignment gets direction-to-direction anchor scatter down to 0.76px and kills the 22px cross-frame drift that AI video tends to inject.

Outputs: dir_1…dir_8 (4-channel RGBA) and info with canvas size, anchor coordinates, and the Unity/Godot normalized pivot - paste that pivot into your engine and all eight directions share one coordinate frame.

Why fixed grid instead of connected components

The pack's other sprite splitter uses connected components, which is right for a single static sheet and wrong for animation: as the character moves, its bounding-box ordering drifts across row boundaries, one frame misorders and the whole animation is toast. A fixed grid can't drift. The crop box is also taken as the union across all frames, so the strip stays one consistent size with no inter-frame jumping.

The traps

First, frame-rate mismatch: Seedance outputs 24fps, so your drop rate and output rate must agree - select_every_nth=3 ↔ frame_rate=8, 2 ↔ 12, 1 ↔ 24. Second, the transparent-webm verification trap: alpha lives in a separate WebM sideband, so default ffprobe shows yuv420p and default decoding reads back fully opaque - that's the built-in vp9 decoder ignoring alpha, not a broken file. Decode with -c:v libvpx-vp9 to actually see it. If your character looks grey on a dark background, edge_shrink is too low.