Browse documentation

What kinds of videos you can (and can't) make

An honest map of the studio's range today.

This page is meant to set expectations honestly, not to sell you on the tool. Every object type in Manim Studio maps to a specific, real Manim construct — there's no hidden "and then a model fills in the rest" step — which means what's expressible is bounded exactly by that object list, plus the animation kinds that can act on it. That's a real ceiling, and it's worth knowing where it sits before you commit an afternoon to a video idea the tool can't actually finish.

What this is genuinely good for

Geometry with live constructions and annotations. Triangles solve their own angles from partial input, and constructions like medians, angle bisectors, altitudes, and incircles exist as first-class derived geometry rather than something you'd have to fake with plain lines. Combined with side labels, angle marks, and vertex coordinate annotations, this is one of the strongest use cases in the app: the object types line up almost one-to-one with what a geometry lesson actually needs to draw.

Calculus visual explainers. Function graphs on real coordinate axes, filled area regions, Riemann sum rectangles, and tangent lines with a live, keyframeable tangentX are all built-in object behaviors, not manual approximations you'd have to hand-place. Keyframing a Riemann sum's rectangle count or a tangent line's tangentX gets you the classic "watch the approximation converge" or "watch the tangent slide along the curve" explainer with very little manual setup.

2D linear algebra. The matrix animation kind applies a 2×2 map about the scene origin to any shape or to a number_plane grid, and the inspector shows you the live determinant and what it geometrically means (orientation flip, collapse to a line, area scaling) as you edit it — genuinely useful for building the standard "watch the grid shear/rotate/scale" linear algebra explainer.

Non-linear plane warps. A matrix, however you set it, can only ever map straight lines to straight lines — that's the whole of what a linear map is, and it's a real limit on what a linear-algebra visual can show. Warps go past it. Applying z² squares every point as a complex number, bending straight grid lines into parabolas; 1/z turns the plane inside out, flinging what sat near the origin outward and drawing the far reaches in; eᶻ wraps horizontal lines into circles. Alongside those there's Fold (the left half of the plane closes onto the right), Ripple (a wave runs through the shape) and Pinch (it squeezes toward its horizontal centre line). Applied to a coordinate plane rather than a single shape, these are the standard complex-analysis visuals — the pictures a lesson needs precisely when a matrix isn't enough.

Curve sweeps. A formula-driven graph can re-draw itself every frame as a value inside its own formula changes, rather than morphing between two fixed poses. The distinction matters more than it sounds: a morph interpolates between a start shape and an end shape and can pass through positions the formula never actually produces, whereas a sweep genuinely re-evaluates the curve at each step. That's what makes travelling waves, spinning roses, and frequency sweeps read as continuous motion instead of a crossfade.

Basic 3D scenes. Solids (sphere, ellipsoid, cube, prism, cone, cylinder, torus, polyhedra including pyramids), parametric surfaces and space curves, and an orbiting camera are all real, WebGL-previewed, Manim-ThreeDScene-compiled object types. This covers a solid range of "show a 3D shape and rotate the camera around it" or "plot a parametric surface" content without needing custom code.

2D↔3D transitions. A family of presets tips a flat shape up into depth and back down again: Stand Up and Lie Down, Unfold to 3D and Flatten to 2D, Lift Off and Settle Down. The conceptual point is worth stating plainly, because it explains why this works at all — a 2D shape and a 3D one are the same object here, just posed differently. Depth is a property the object always has, so "become 3D" is a change of pose rather than a conversion into some other kind of thing, and the flat drawing standing up off the page is exactly what you see.

Graph theory traversal animations. The graph object's graphStyle animation kind recolors one vertex or edge at a time; chaining several of these on staggered start times is exactly the mechanism for building a BFS/DFS/Dijkstra-style "watch the frontier expand" traversal animation, one node lighting up after another.

Step-by-step algebraic derivations. The derivation object plus TransformMatchingTex (see How compilation works) gets you term-matched morphing between algebraic states in the actual render — a real strength for walking through a multi-step proof or simplification, keeping in mind that the live preview shows a cruder step-switch, not the render's actual sliding morph.

Per-symbol animation. You can address ONE symbol or term inside a formula rather than the whole line, which is most of what explaining maths actually consists of: pointing at a particular thing. A single term can be pulsed, circled, or isolated by dimming everything else around it — and beyond drawing the eye, it can genuinely move, rotate, resize, morph into a different symbol, or be pulled out of the equation, held aside, and put back with the formula left intact. A term visibly travelling across the equals sign explains more than any amount of highlighting does. This works on plain text too, not only on formulas. See Animate one symbol.

Freeform vector illustration. The Canvas studio's pen/pencil tools, SVG import, and point-level path animation are a genuinely separate but capable toolset for hand-drawn or imported vector artwork with per-anchor keyframing — see Editor vs. Canvas for why it's kept as its own workspace.

Simple rigid-body physics demos. A baked simulation pass solves object trajectories in advance and replays them as a per-frame position/orientation updater in both the preview and the compiled scene — good for a basic "watch objects fall/bounce/collide" demo, not a general physics engine.

Sharing a live scene. A finished scene doesn't have to become a video file to be shared. It can be sent as a link that plays in the browser, with you choosing what the viewer is allowed to do — play it, orbit a 3D scene, zoom in — and you can expose specific numbers for them to change and watch the scene respond in real time. That last part is the interesting one: a reader who can drag a radius and see the construction follow has understood something a fixed clip can't teach them. See Share a scene with a link.

Where the real ceiling is

Being specific here matters more than being reassuring, so:

  • Vector field streamlines are supported, but only as an alternate render style. The vector_field object compiles to Manim's ArrowVectorField by default (a static grid of arrows sampling F(x,y)F(x, y)), or StreamLines (flowing particles along the field, with start_animation) when you switch its Style to "Flowing streamlines" — see the object's Style dropdown in the inspector.
  • No true 3×3 matrix preview. A 3D linear transformation's shear component is invisible in the 2D canvas — you can only preview its upper-left 2×2 block — and the actual result is render-only. See Preview vs. render for why.
  • Procedural spawning exists, scoped to one rule per object. Any object can carry a spawn rule (Info tab → "Procedural spawn") compiling it into N copies via a Python for-loop, each shifted/rotated/scaled/recolored by an expression in the copy index i — the "200 dots following a rule" case. This is a single, contained escape hatch (one rewritten VGroup(*[...for i in range(count)]) assignment), not a general "write arbitrary Python" hatch — per-copy logic is limited to what the four expression fields (dx/dy/rotation/scale) plus a color-gradient expression can express.
  • Multi-scene/chapter export exists, alongside the single-timeline default. A project is still authored as one continuous timeline, but the code view (Scene panel → Export → "View generated Python") can split it into one independent Scene class per chapter marker instead of one continuous class with self.next_section() splits — each chapter is separately manim render -s <ChapterName>-able. Markers not already sitting at a rest point (no animation in flight) are silently snapped to the nearest one, with a warning, since Manim can't reconstruct a scene's state mid-animation for a fresh class to pick up from.
  • SVG import handles arcs and transforms now, with one caveat. Arcs (A path commands) convert to real cubic Bézier curves via the standard endpoint-to-center parameterization, and transform attributes (translate/rotate/scale/skew/matrix, at any ancestor <g> or the element itself) are composed and applied. The one remaining rough edge: an arc command's large-arc/sweep flags glued together with no separator (a2 2 0 11 2 2) are only split correctly when a single arc command appears once per letter in the path data; a run of several arcs chained after one shared a/A (a shorthand some tools emit) can still misparse the flags on later arcs in the chain.
  • A layered matrix object and any 3D-rotated path force the whole scene into 3D. A layered matrix object, or a Canvas-studio path with nonzero depth or 3D rotation, is treated as sufficient reason to compile the entire scene as a ThreeDScene rather than a plain 2D scene — even if every other object in the scene is flat 2D geometry. That's not free: a ThreeDScene has its own camera model and its own lighting/shading behavior that differs from the plain 2D scene the rest of your objects were designed against, so adding one 3D-ish element can change how everything else in the scene behaves.

The honest framing

This is a deliberate scope, not an oversight or a missing feature waiting to be filled in later — the tool trades the openness of "just write Python" for a UI where every object is a known, predictable, inspectable quantity with a live preview and a deterministic compile. That trade is worth it for the categories above and genuinely not worth it the moment you need custom procedural logic or a true escape hatch. The actual, current, up-to-date boundary of what's expressible is the object reference — every capability and every limitation ultimately traces back to what's on that list, so when in doubt about whether something's possible, that's the page to check first.