Overview

• Animation rules for multi-scene compositions
• Energy and mood transition selection
• Narrative position
• Blur intensity
• Presets
• Implementation
• CSS vs shader guidance
• Shader-compatible CSS rules
• Visual pattern warnings

Animation Rules for Multi-Scene Compositions

These are non-negotiable for every multi-scene composition:

1. Every composition uses transitions. No exceptions. Scenes without transitions feel like jump cuts.
2. Every scene uses entrance animations. Elements animate IN — opacity, position, scale, etc. No scene should pop fully-formed onto screen. Use gsap.fromTo() (not gsap.from()) so the start state is explicit: from() animates to current CSS, so pairing it with CSS opacity: 0 is a 0→0 noop and the element never appears (see /hyperframes-core → sub-compositions).
3. Exit animations are BANNED except on the final scene. Do NOT use gsap.to() to animate elements out before a transition fires. The transition IS the exit. Outgoing scene content must be fully visible when the transition starts — the transition handles the visual handoff.
4. Final scene exception: The last scene MAY fade elements out (e.g., fade to black at the end of the composition). This is the only scene where exit animations are allowed.

You are NOT done after this file. This overview gives you which transition and when. Before writing any transition you MUST open catalog.md in this directory for the GSAP code and the hard rule every transition follows — position new scene → animate outgoing → swap → animate incoming → clean up overlays — plus the per-category css-*.md files for specifics. Authoring transitions from this overview alone is how you end up shipping the ❌ pattern above.

Energy → Primary Transition

Pick ONE primary (60-70% of scene changes) + 1-2 accents. Never use a different transition for every scene.

Mood → Transition Type

Think about what the transition communicates, not just what it looks like.

Narrative Position

Blur Intensity by Energy

Presets

Implementation

Read catalog.md in this directory for GSAP code and hard rules for every transition type, and the css-*.md files for per-category implementation details.

Transitions That Don’t Work in CSS

Avoid: star iris, tilt-shift, lens flare, hinge/door. See catalog.md for why.

CSS vs Shader

CSS transitions animate scene containers with opacity, transforms, clip-path, and filters. Shader transitions composite both scene textures per-pixel on a WebGL canvas — they can warp, dissolve, and morph in ways CSS cannot.

Both are first-class options. Shaders are provided by the @hyperframes/shader-transitions package — import from the package instead of writing raw GLSL. CSS transitions are simpler to set up. Choose based on the effect you want, not based on which is easier.

Mixing is supported. You can have some transitions use WebGL shaders and others use a CSS crossfade in the same composition. Omit the shader field on any TransitionConfig entry to get a smooth opacity crossfade instead of a WebGL effect:

HyperShader manages all scene visibility regardless of transition type. Let it create the timeline (don’t pass timeline: into init()) and add your beat animations to the returned tl after the call.

Shader-Compatible CSS Rules

Shader transitions capture DOM scenes to WebGL textures via html2canvas. The canvas 2D rendering pipeline doesn’t match CSS exactly. Follow these rules to avoid visible artifacts at transition boundaries:

1. No transparent keyword in gradients. Canvas interpolates transparent as rgba(0,0,0,0) (black at zero alpha), creating dark fringes. Always use the target color at zero alpha: rgba(200,117,51,0) not transparent.
2. No gradient backgrounds on elements thinner than 4px. Canvas can’t match CSS gradient rendering on 1-2px elements. Use solid background-color on thin accent lines.
3. No CSS variables (var()) on elements visible during capture. html2canvas doesn’t reliably resolve custom properties. Use literal color values in inline styles.
4. Mark uncapturable decorative elements with data-no-capture. The capture function skips these. They’re present on the live DOM but absent from the shader texture. Use for elements that can’t follow the rules above.
5. No gradient opacity below 0.15. Gradient elements below 10% opacity render differently in canvas vs CSS. Increase to 0.15+ or use a solid color at equivalent brightness.
6. Every .scene div must have explicit background-color, AND pass the same color as bgColor in the init() config. The package captures scene elements via html2canvas. Both the CSS background-color on .scene and the bgColor config must match. Without either, the texture renders as black.

These rules only apply to shader transition compositions. CSS-only compositions have no restrictions.

Visual Pattern Warning

Avoid transitions that create visible repeating geometric patterns — grids of tiles, hexagonal cells, uniform dot arrays, evenly-spaced blob circles. These look cheap and artificial regardless of the math behind them. Organic noise (FBM, domain warping) is good because it’s irregular. Geometric repetition is bad because the eye instantly sees the grid.