RIVX

A two-dimensional player composites a draw order rather than solving arbitrary per-pixel scene depth. As a camera orbits, faces may change their relative painter order. One shared mesh in one fixed position in the tree cannot necessarily represent every pose, even if its vertices can be animated perfectly.

The slot-based export distributes reused faces among an order-compatible sequence. Stable identity, matching topology, color, winding and placement constraints determine what can fold. If those conditions fail, the exporter falls back to another tier rather than silently reorder the image. Rings or other primitives that switch between an ellipse and multiple clipped arcs can still require pose-specific representations.

The new export preflight refuses reuse when ordered texture coordinates, mesh topology or pose identity differ. Refusal also propagates across overlapping ordered slots, preventing a foldable foreground mesh from moving behind a neighboring fallback mesh. Asset pruning then removes only images no final drawable references.

Scene3D mesh pose keys currently use HOLD interpolation. This preserves the authored pose snapshots; it is not a continuous camera solver. Smooth interpolation of projected vertices cannot reliably interpolate perspective, changing visibility or paint order. Compact parameter motion such as a gradient sweep is a different and more favorable keyed case.

The cube study makes this conversion concrete. Perspective projection is sampled into scalar animation tracks at 60 fps, and the official Rive runtime plays those keys. The host reads back the selected vertex’s position for the curve readout; it does not reposition the drawing. This preserves a smooth authored orbit while making the remaining limitation visible: a new camera projection requires new keys.

The richer keyed fixture deliberately separates shape from appearance. A circle’s projected contour is keyed as geometry; a photon-baked receiver is carried by an image mesh; the foil sticker has color tracks; glass uses sampled embedded images. Adding layers exposes the corresponding track families. This illustrates the same geometry-versus-appearance tradeoff as the larger native orbit without reusing images from an incompatible camera.

Once projection is back in ordinary Rive, the drawing can change without GPU Canvas. The follow-up replaces sampled glass and textured surfaces with engraved curves or cut-paper tones. The same projected sphere silhouette, layer controls and 60 fps orbit remain keyed Rive geometry. These authored vector styles retain a scene’s motion while choosing a different appearance; they do not need the original shader or a live refraction solve.

An animation exporter can fold corresponding objects across sampled poses and key the properties that change. Correspondence requires compatible structure: path topology, material kind, image binding and ordering cannot be treated as arbitrary numeric channels. If a shape changes its role or topology, forcing it into an old slot can create a small file that draws the wrong scene.

Painter order is similarly structural. Rive’s serialized child ordering must be matched to the intended paint stream; reversing the relationship can produce a perfectly readable file with incorrect occlusion. The reduction reported in the existing fixture counts drawable nodes separately from all serialized components because additional keyed properties can increase the latter even as the visible tree shrinks.

Orthographic projection supplies useful geometric simplifications, including circles projected as ellipses at a fixed pose. It does not make arbitrary temporal interpolation exact. Between authored keys, the player follows the supported animation channels, so the sampled pose domain and interpolation error remain part of the export contract.

A documented 152-pose fixture reduced the drawable tree from 70,119 to 1,579 while making the file about 15 percent smaller. Total serialized objects increased because keyed properties have their own objects. This is a useful concrete result precisely because it distinguishes drawable reuse from universal compression, and because short sequences may not repay the keying overhead.

In a two-wall 120-frame fixture, drawable reuse reduced serialized components from 1,562 to 135. A held-camera file fell from 49,090 to 17,592 bytes; the moving-camera keyed result was 28,064 bytes. The held-camera semantic update improved slightly, but the moving case became slower. That is exactly why file size should not stand in for playback performance.

These timings use official import and property replay through a non-rendering factory. They exclude GPU drawing and PNG decoding. The larger historical 152-pose result remains a separate case study; neither fixture supplies a universal compression or frame-rate factor.

A separate asset-liveness fixture retained one referenced PNG out of eight supplied assets, reducing 34,389 to 4,814 bytes. This removes unused data. It does not discard the required view-dependent refraction images or imply that keyframes can regenerate them.

The live isocurve pipeline below samples a lit scene, extracts closed tone boundaries and draws them with official Rive. Move the light or camera and the paths change. The fitted-ellipse and photon-relief studies offer two other ways to turn appearance into actual geometry.

This is also a study of how to design for Rive’s drawing budget. Tone bands, coherent strokes and a small set of soft marks can preserve the structure of a scene with different costs and editing possibilities. The aim is to find useful vector encodings and measure their error and workload. A shader can supply the lighting field while the final contours remain ordinary Rive geometry.

The preset “* Ink and tone: the drawing, analytic” combines Hatch and Inkline on the same built-in scene. Hatch starts in Flow / Gradient with coats off, so tone is carried by strokes; Inkline adds creases, object contours, sphere terminators and shadow boundaries as separate line classes. This route works from the scene and analytic illumination approximation, rather than vectorizing the final color image.

The Hatch node now exposes eleven patterns: Lines, Dots, Scribble, Relief, Oneline, Ink spiral, Stained glass, Flow, Hilbert, Isolines and Adaptive. The shared colour and normalize-tone controls allow the drawing language to change without replacing the underlying tone source. This is a more focused demonstration than cycling unrelated screen filters.

The native Iso node already emits ordinary Rive-compatible paths and works with both official and enhanced renderers. It is not desktop-only by design. This browser counterpart demonstrates the conversion; the full native graph, gradient/feather fitting and depth-of-field extensions remain separate.

Illum, Hatch, Brush and Cel use an analytic direct-light/shadow construction for the supported scene geometry. Exact subproblems such as a boundary or Voronoi clip do not make the entire image an exact global-illumination solution. Repaint is explicitly a fit, and its Rive soft-lobe appearance remains an approximation.

The flow recipe can follow an isophote, the illumination gradient or a motion-derived direction. For the velocity option, correspondence between poses is pulled back into the face coordinates before generating marks. Near-singular mappings and negligible screen motion are gated, so a stationary camera can legitimately produce no velocity-oriented strokes. That behavior is different from a procedural swirl that continues regardless of motion.

The stained-glass recipe clips local surface cells against Voronoi bisectors. Its lead is formed by inset boundaries rather than a blurred edge pasted over the final image. The partition and its outlines share the same face coordinates. In both cases, the intermediate field or cells explain the result more clearly than a final stylized screenshot alone.

The eleven current hatch patterns are not eleven interchangeable filters. Some distribute tone by coverage, some generate an ordered ribbon, and some construct a partition. The preset table above is therefore organized around the representation and field used, with repaint and illumination layers kept distinct.

The controls are part of the composition. Material Nocturne and Resonant Membrane use springy liquid handles; Spectral Observatory uses constructive, Mondrian-like geometry. Hover, press and drag to see their response. In Resonant Membrane, a strike chooses the modal weights; the surface, nodal drawing and optional browser-generated sound follow the same excitation and decay. Its visual GPU Canvas document is self-contained; procedural audio uses a small Web Audio bridge.

The four established showpieces are authored and signed with the official Rive CLI. The public gallery presents the working instruments; editable documents and source archives are kept outside the public site. This standalone authoring route is separate from the native RIVX desktop exporter. The official CLI watermark remains visible.

The two formats serve different deployments. GPU Canvas keeps a bounded visual instrument together inside Rive. A host bundle can connect its Rive interface to an existing renderer, browser libraries and external scene data. In either form, a parameter changes the GPU model and the Rive explanation together.

The visual and mathematical vocabulary comes from related portfolio projects: compound-material lighting in LTC, optical studies in Aperture, and excitation, decay and nodal patterns in Modal2D. These are focused adaptations authored for Rive, with shared controls driving both the image and its explanation. They do not package the complete source applications or their full solvers inside a .riv.

Prismatic Garden connects this instrument work to High-dimensional Fields & Shadow Design. The surroundings keep a fixed Julia parameter while the movable prism reveals a time section through nearby parameters. The gold Rive path and orbit follow the same section; W moves the path and a tilted mode couples image position to time. GPU Canvas can express this fragment-shader study too: its distinction is the linked mathematical instrument and its delivery contract, not a rendering effect exclusive to RIVX.

Material Nocturne combines analytic geometry with finite rectangular-light quadrature and a GGX material response. The native plot follows roughness and the light marker follows the controls. Studio reflections and the floor caustic are approximations; this scene does not implement fitted LTC tables or a general path tracer.

Spectral Observatory traces seven wavelength bands through a sphere and prism with wavelength-dependent refraction and absorption. The native plot shows the same index model. RGB reconstruction, receiver caustics and visible shafts are bounded approximations rather than converged spectral transport.

Resonant Membrane connects Modal’s eigenmode and audible-decay teaching ideas to a Rive instrument. A nine-mode fixed-edge square membrane weights each mode by its value at the strike position. The GPU surface and ordinary Rive diagram share these coefficients and damping; Web Audio plays them at audible frequencies while the visible oscillation is slowed. This is an analytic teaching model, not the full Modal finite-element backend or simulated sand.

Liquid optics makes lens position, refraction, dispersion and frost directly controllable inside the signed document. Hover feedback and drag surfaces are ordinary Rive interaction around the embedded GPU image. This is a stylized optical instrument, with its visual approximations kept distinct from a general spectral path tracer.

Prismatic Garden holds the Julia family fixed and reveals another parameter section under a movable prism. Time traverses a periodic ellipse in the complex parameter plane, W offsets that path, and a tilted mode couples vertical position to phase. Ordinary Rive paths draw the parameter loop and current orbit. This relates to the sectioning idea in High-dimensional Fields & Shadow Design; it is not its complete 5D volume renderer. The optical effect uses designed RGB transmission.

The base pass rasterizes depth-tested triangles with visible edges. Analytic ray intersections add bounded reflection and refraction. Photon rays follow the flashlight through dielectric entry and exit to their first receiver; post-glass segments also reconstruct volume caustics. Show photons outside aperture adds those traced contributions to the raster world. Rays missing the glass contribute no glass caustic.

The temporal window selects source-to-sample optical path length: air distance plus refractive index times the distance inside glass. The camera leg is omitted, so this is a source-clock pulse view rather than a camera-return time-of-flight measurement. The medium is a single-scattering approximation; the photon reconstruction is deliberately biased.

Torch brightness scales source power before tone mapping. Yaw and tilt offset the continuous aiming direction. Disk and five-point-star emitters sample finite source areas with fixed total flux; direct surface illumination uses bounded quadrature and direct fog keeps a central-source approximation. RGB dispersion traces three index bands through the glass, receiver and volume beams. It is geometric three-band dispersion, not a continuous spectral solver. These new settings use host controls beside the ordinary Rive instrument, and survive both setup lists and Suite export.

While a control moves, a small 512-ray batch supplies feedback. After the scene rests, independent batches accumulate into a fixed-memory linear running mean for both receiver and beams. Refinement has no batch cap. This reduces sampling noise with a fixed reconstruction kernel; it is not progressive photon mapping with a shrinking radius or a converged full-transport solver.

The base raster, ray and photon evaluations use vertex/fragment render passes. Living fog adds a separate compute simulation before those passes. This browser route is a RIVX Suite: ordinary Rive content, a host and GPU programs. An earlier companion GPU Canvas document was compiled and rendered in the official local CLI; these enriched materials, media and controls have not been copied into a newly signed all-in-one document. Neither artifact implies a complete port of RIVX Draw.

Living fog retains density, heat and face velocities on a 40 × 32 × 40 grid. Developed plumes are seeded once, then semi-Lagrangian advection, buoyancy and vorticity confinement move that state. Fourteen weighted Jacobi iterations approximate pressure projection. The spheres, cube, pedestal and chamber walls act as voxelized obstacles.

Smoke source controls the three floor emitters. Stirring applies an artistic helical air jet along the aimed flashlight cone; it is not radiation pressure. Heat in the smoke reveals the retained temperature field. Freeze flow holds the density so stationary photon batches can refine the lighting. Reset plumes restores the seed, while switching the optional toggle off returns to the selected procedural medium.

One density field supplies direct fog, source-to-surface extinction, refracted volume beams and photon receiver extinction. Short density columns also attenuate the camera view, and a bounded ambient fill makes unlit smoke readable. Entry and exit air segments are treated separately from travel inside glass. This remains a single-scattering visual approximation and finite photon reconstruction, not complete heterogeneous or multiple-scattering transport.

The flow advances at most 30 times per second with no catch-up burst after suspension. Live flow uses at most 2,048 photons per batch; a frozen volume restores the selected full count. The coarse grid, first-order advection, limited pressure iterations and faster top-layer dissipation favor a responsive visual study over a calibrated fluid experiment.

Suite export includes the compute module and shader alongside the ordinary Rive interface and renderer. It preserves the settings, then reloads Living fog as a frozen seeded setup; the evolved volume is not serialized. This browser companion does not mean the native RIVX exporter automatically generates fluid simulations.

GPU Canvas currently exposes vertex and fragment shaders, with up to four bind groups. Its documented WGSL subset excludes compute shaders, override declarations, subgroup operations and non-uniform resource indexing. These are current API limits; they are not a judgement about which visual styles belong in Rive.

Living fog dispatches grid updates into persistent simulation buffers and a 3D density texture. The photon-receiver companion assigns a compute invocation to each photon and uses atomic additions when paths reach the same cell. The browser owns those pipelines, resource lifetimes and dispatches; their current compute execution paths cannot be placed directly into the documented GPU Canvas API.

That execution gap does not make smoke or caustics impossible without compute shaders. NVIDIA’s GPU Gems Chapter 38 implements fluid advection and pressure projection with fragment programs and render passes. Reworking this solver around another resource layout and rendering algorithm is a separate engineering route, not a port demonstrated here.

Prismatic Garden and Flashlight Atlas’s base optical passes remain render-pass algorithms; their visual effects are not exclusive to this host. Living fog is the new compute addition within Atlas. A full learned-Gaussian export is also simply not implemented here. The paired gallery demonstrates the delivery routes that already exist.

A graph layer carries the geometry and camera context needed downstream, rather than being just an unnamed color texture. That allows a raster view, a pattern generator and an export node to refer to the same scene. Clock is a separate input: advancing an observation window need not imply generating an unrelated photon population.

The evaluation plan distinguishes expensive static work from pose-dependent work. TracedPaths can produce the retained transport population; PhotonLightmap can deposit it onto surface charts; an illumination, hatch or splat node can choose a display vocabulary. The camera then projects that result. A camera input attached to a baked representation does not make the underlying lightmap camera-dependent. Geometry, light or material edits can invalidate the bake, while an ordinary camera orbit can reuse it.

This separation is also the basis of the preset comparisons. Changing only the final representation exposes its approximation; changing the tracer, lightmap and display together would mix several causes. The recipes above name actual graph presets, while the full node reference documents the inputs and the recomputation rules.

The official route is the compatibility baseline and the normal choice for standard Rive drawing. RIVX Draw, our working name for the enhanced backend, is a renderer adapter below the same official animation evaluator. It receives actual paths and transforms, then chooses how to rasterize or reinterpret them. That makes it useful for specialized coverage, feathering, shape-aware fields and the vector-beam drawing model—not merely a second preview window.

In native beam mode, the custom renderer collects transformed contours from the evaluated artboard. An ordered moving spot follows that geometry, and an analytic segment integral deposits energy into a persistent phosphor buffer. A final-image filter cannot recover that exact source draw stream from pixels. The browser effect workshop has a useful image-derived contour treatment, but it is a different input contract. Native contour capture exposes the raw drawn contours before general clipping/opacity treatment, so it is not automatically a visible-silhouette extractor.

Scene3D’s “No-Rive” option is a third route: direct GPU rendering of its own retained geometry, fields and splats. It is useful as a reference and for primitives outside the ordinary Rive vocabulary. Internally this scene option also uses the label “Ours”; it should not be confused with the top-level custom Rive renderer.

A standard .riv export does not need the custom backend once its result has become supported Rive shapes, images and keys. A live custom drawing behavior needs either its own playback implementation, an authored GPU Canvas implementation, or a bake. Saving parameters in a native .rivx project preserves the recipe; it does not embed a portable implementation of the renderer.

The browser instrument below now carries one enhanced drawing behavior through the whole pipeline: official Rive evaluates the source animation, a command adapter captures its animated paths, a custom beam renderer draws them, and an ordinary Rive reticle tracks the beam while a bound rectangle marks the selected path. The standalone HTML export carries that browser implementation. This is a focused portable renderer, with its own supported subset, rather than a port of the complete native backend.

The direct “No-Rive” switch describes an intermediate drawing route, not a ban on Rive export. Its results can later become supported paths, images or keyed poses. A pure WebGL export is appropriate when the delivered scene has no Rive layer at all. A custom effect survives in ordinary .riv only when represented by supported content or baked; otherwise its specialized player must travel with it.

The custom renderer implements the Rive renderer and factory interfaces so the same scene can be replayed through either backend. Its immediate stencil-and-cover path handles each shape individually: flatten and tessellate, establish clipping and winding coverage, cover the shape, and composite its paint. This exposes the shape at the point where additional information or behavior can be attached.

The official renderer is open source, but the ordinary integration boundary provides a completed render rather than all of those bespoke intermediate buffers. Its execution strategy records draws and organizes a logical flush: gradient data and tessellation are prepared in batches, compatible work is grouped, and coverage is resolved through its rendering pipeline. The custom renderer instead flattens and uploads paths and performs stencil/cover work shape by shape. The comparison is therefore about data access and amortization, not a universal ranking of C++ implementations.

A dense cloud represented by one custom instanced batch is not the same workload as a cloud expanded into thousands of runtime shape components. Conversely, a frame containing many ordinary vector paths can favor the official renderer’s deferred batching over the custom per-shape route. Both comparisons can be useful when the representation is stated.

The current engine document supersedes earlier broad speed ratios. It tracks the actual rendering mechanisms and identifies missing general path/transform caching in the custom route. Feature parity also needs to be checked: the custom path caps gradients at sixteen stops, falls back to source-over for unsupported advanced blends, and uses approximations for some fixed-function blend combinations. A quicker frame produced by a reduced operation is a different result.

For an exported scene, the ledger includes drawable nodes, total serialized components, image assets, keys and per-frame player work. A smaller drawable tree may still use more total components; fewer draw calls may still process a large overdraw footprint. Those quantities are kept separate in the exporter’s evidence.

The next reusable layer is a contract for information: which pass owns it, its coordinates and units, how long it lives, and how it changes when a control moves. Native shape-aware fields, special curve/splat types and the browser signal-history sweep already provide concrete starting points.

A heavily interlaced Rive/GPU instrument is also possible in a Suite, but it needs an explicit dependency graph, synchronized state, clipping and resource lifetime. The goal is to make that coordination routine. More canvases or more impressive shaders alone do not establish an exclusive RIVX capability.

A general 4D field API, automatic graph lowering into signed GPU Canvas, and universal native-backend browser parity remain proposed work. The extension brief separates those proposals from the working examples.

Moving an interpolated control point changes the local construction without arranging Bézier handles. The extension lives in that retained model and evaluator. Both the native renderer and this browser study sample the evaluated curve for display; neither label promises an infinitely exact rasterization.

The native Cubic Pen already uses ordinary cubic Bézier vertices and keeps those vertices in .riv. The native B-spline and Yuksel export instead writes a polyline. Curve Atelier uses narrow filled quadrilaterals for its line segments. A fitted cubic approximation would be another conversion method; it is not the exporter shown here.

The native selector exposes Gaussian, Atlas and Analytic modes. Gaussian passes blur coverage; atlas coverage is a separate approximation route; the distance-based route evaluates a profile around the boundary. The analytic erf expression is exact for a straight boundary under Gaussian blur, not for every curved shape.

A native Gaussian primitive instead retains its covariance and evaluates that field. The portable exporter can fit supported feathered ellipses; the live browser comparison below uses layered ellipses. These are separate constructions with separate fidelity and cost limits.

The training route captures the selected renderer through an explicit camera rig, writes its dataset, invokes the Gaussian trainer and imports the resulting artifact. Scene geometry can seed the initial distribution rather than forcing a generic enclosing shell to discover every surface. The chosen image source also matters: a flatly lit capture does not contain the same shading evidence as a richer path-traced target.

The recorded planar example above is one concrete run, with its own train/test views and saved evaluation. Its success applies to that captured domain. A low image error on an outside planar rig does not establish equally good reconstruction for an unobserved ceiling or a different orbit. The diagnostic distinction is coverage versus fit: an omitted surface requires additional observations, while an observed but poorly fitted surface may need a better distribution or optimization.

The import path also has a data-lifecycle responsibility. A trainer can rewrite the same output filename, so the application checks file state rather than assuming an unchanged path means unchanged content. Advanced fitted output should remain associated with the capture and settings that produced it, instead of being silently replaced by a quick-preview profile.

Precision is a pipeline-specific constraint. The official bridge quantizes colors and alpha through ColorInt, and the inspected official render target uses RGBA8. The custom Scene3D accumulation can use RGBA16F and apply one display transform at the end; this improvement does not change the standard .riv color representation. Dense low-opacity layers therefore need different treatment from a few ordinary opaque vector shapes.

Start from existing Rive artwork or a supported 3D scene. Add an appearance, change its controls, then choose whether delivery should carry the finished drawing, a live shader instrument or retained scene data and its viewer. These are three presentation strategies; the native .rivx project is the editable source record.

The desktop studio is the authoring workbench. These browser laboratories make selected operations directly testable: fit splats, apply image and time effects, move an optical lens, edit the relay’s glass and lighting, and reopen the resulting exports.

Many of these demonstrations adapt work already explored elsewhere in the portfolio. RadianceLab supplies the photon and transient-rendering research; the native RIVX labs supply scene and drawing experiments; LTC, Aperture and Modal2D inform the material, optics and modal instruments. The contribution here is connecting those methods to Rive interaction, vector explanations and a deliverable that preserves the intended behavior.

RIVX is the project; Studio is the authoring workbench. We are using Draw and Suite as provisional labels to separate an enhanced renderer from a deliverable. They do not rename existing file extensions or imply one universal .rivx loader.

A Suite can contain official Rive plus an external shader, a focused port of Draw’s beam behavior, or a retained custom-WebGL scene. It carries the player required by that example. An ordinary .riv produced in Studio can play in official Rive without Draw.

An optical pass can be added to any source that the selected Rive runtime renders. In the browser workshop, its input is the rendered image; edge response uses image gradients. This gives useful distortion, reflection and dispersion without editing the original document’s objects. It does not infer hidden surfaces or identify physical glass from pixels.

The native custom renderer can expose shape identity, paint order, motion and geometric auxiliary fields. Effects consuming those fields can be more selective. The official framebuffer alone supplies none of that identity, and a 2D paint-order depth buffer is not a reconstructed 3D scene. The interface should make that distinction visible before export.

GPU Canvas makes richer live evaluation inside a Rive document practical, but the scene representation and effect logic must still be authored for it. The working signed showpieces demonstrate that destination today; the native Browser delivery button currently packages the external renderer route.

An effect is a small render program: named input textures, scalar parameters, one or more passes and an output target. Inputs can be the original image, the previous effect, an auxiliary field, a persistent simulation state or a previous frame. This makes intermediate state part of the composition rather than an invisible implementation detail.

The strongest comparisons expose the field that changes the result. Edge-tangent flow aligns marks with image structure; motion vectors transport a previous stylized frame; contour samples can drive an ordered pen path. A shader that derives gradients from color is image-aware, whereas an effect reading geometry-produced IDs or contours has additional information that color alone cannot recover.

The browser workshop now runs the heavier processes too: an orbitable x/y/time texture volume, motion density, iso-sheets, STM luminance relief, ordered contour traversal and a persistent phosphor buffer. It can feed the beam output into the time volume. The official runtime continues to drive the source artboard and its timelines or state machine. Browser contours come from image extraction; the native engine can instead use original path geometry and auxiliary scene buffers.

The included glass source is the 600-angle recording authored at 60 fps. The shader path follows display refresh, with a measured frame-rate readout and an adaptive volume-quality option. The layered Rive splat view updates a reusable pool of ordinary ellipse shapes instead of rebuilding a document for each animation frame. A self-contained HTML export preserves the original .riv, custom stages and retained history; a separate .riv snapshot export preserves a static layered vector drawing.

Each registered effect names its parameters and passes. A pass declares the shader, input textures, constant uniforms, output destination and primitive. This makes multi-pass effects reproducible: the code specifies whether a shader sees the untouched artwork, the previous effect’s output, an earlier pass of the same effect or a derived auxiliary field.

History refers to the preceding final image. State is an effect-owned ping-pong buffer, used for an evolving field such as reaction–diffusion. Several State passes may run in one displayed frame before a colorization pass produces the result. Replacing History with State would change the recurrence, even if both happen to be textures.

The saved RIVX pipeline records effect configuration, ordering and parameters. It does not serialize live OpenGL objects or promise to resume every feedback simulation at the exact same internal phase. On reload, the configured computation is rebuilt.

The registry includes evolving fields whose parameters are modulated by the scene and its auxiliary buffers. For example, the flow-advected reaction–diffusion chain binds the original scene, the previous State, noise, ETF and curvature, performs several update passes and then colorizes the field. The result follows the drawing because its inputs contain that drawing’s structure.

These are explicit discretized recurrences with a chosen step size, iteration count and display mapping. Changing passes per frame changes the field evolution per displayed second unless time is compensated. A chemical-looking pattern, a smoke-like advection or a particle trail in this postprocess region should consequently be interpreted through that effect’s implementation, separately from the Scene3D photon estimator. The common pipeline makes those choices inspectable rather than hiding them behind a style name.

Phosphor persistence compresses previous illumination into one decaying image. It can show a beautiful trail, but it cannot generally recover the shape at an arbitrary earlier instant. A sequence of vector snapshots or image slices keeps that instant separately addressable.

The direct instrument retains bounded geometric samples and their timestamps. The image workshop stores a circular texture history; its volume is 2D appearance plus time, not recovered physical scene depth. The glass atlas stores authored pose images. Each query should therefore name both its signal and its clock: animation time, sampled pose, or optical travel time.

The custom renderer can identify shapes directly instead of trying to recover object boundaries from their displayed colors. The auxiliary producer uses geometry and rendered identity to provide inputs such as boundaries, distance, curvature, orientation and motion. Derived fields retain their construction scale: a pixel-grid distance or curvature estimate is not an analytic property of the original Bézier curve.

The meaning of depth depends on the source. Both the 2D replay's depth-like channel and Scene3D's NPR auxiliary depth encode painter order. The separate Scene3D ZBuffer renderer uses geometric camera depth. Those are different outputs: the presence of spatial geometry does not make every auxiliary channel a metric measurement.

The contour route follows the occupied boundary, simplifies it with Douglas–Peucker and then resamples by arc length. Tracing produces an ordered boundary; simplification removes points within a geometric tolerance; resampling supplies a more uniform sequence for curve effects and beam motion. Uniform vertex indices alone would make a beam accelerate through sparsely sampled sections and linger in densely sampled ones.

This path is primarily a dominant-silhouette extraction route. It should not be read as a reconstruction of every internal stroke, nested contour or hidden semantic object. The original contour view, the simplified polyline and the downstream resampling are distinct intermediate results. Keeping them visible makes a broken silhouette or a lost narrow feature attributable to a particular stage.

Lab3D is the earlier direct experiment, including beam and analytical export routes. Scene3D, labeled 3D_new in the application, organizes scene authoring, retained photon paths, bakes and keyed exports as a graph. Their overlapping controls do not imply identical timing models or export coverage.

The Scene3D graph separates the expensive transport calculation from its representation. TracedPaths retains a reusable world-space photon cache. PhotonLightmap gathers deposits onto scene faces; points, beams and swept primitives expose the same transport through different geometries. Camera projection and display are downstream choices.

A wall bake spends work once to produce textures. A live primitive layer instead projects and draws retained path information each frame. A Clock can drive both, but it does not retrace the whole scene on every scrub. Geometry or transport edits may invalidate a bake, which is why stale-state indicators and explicit rebaking are part of the workflow.

The practical branch minimizes the amount of live drawing needed to preserve the image. Path tracing and photon gathers can bake surface illumination; Gaussian captures provide another fitted appearance route. Reflection and refraction can be stored as view-dependent image layers. A smaller live photon layer retains spatial or time-of-flight structure where that structure is the point of the demonstration.

The custom Scene3D ZBuffer route is a dedicated rendering path rather than an accidental property of the 2D shape renderer. Planar polygons carry projected depth, while sphere fragments unproject a camera ray, intersect the analytic sphere and write the curved surface depth. Textured sphere displays use that same curved-depth logic. This prevents a sphere-shaped image from behaving like a flat billboard where it intersects another surface.

An ordinary Rive drawing has no equivalent arbitrary per-fragment world-depth computation. Export uses ordered objects and available clipping or decomposition instead. A snapshot can therefore preserve a particular visibility configuration while an unrestricted camera move would require new geometry or another retained-scene renderer.

Opaque surfaces, blended lighting overlays and clipping fallbacks also have distinct visibility rules in the native path. A comparison should identify which route generated the image, especially around transparency, overlapping soft primitives and surfaces that exchange order during animation.

The glass layer is more specific than an arbitrary image warp. The renderer computes the sphere’s reflection/refraction mapping against the scene and bakes that result into a textured disc. During camera interaction it can use a draft image and rebuild the finer image when motion settles. The diffuse wall images remain reusable because their illumination does not depend on the eye. Rough response and recursion limits remain properties of this reduced representation.

Screen-space blur is a reconstruction/display choice with a footprint budget. It makes a sparse projected primitive population readable, but does not manufacture untraced paths or correct an estimator’s sampling distribution. The point, beam and swept views below are therefore useful both as images and as inspections of which geometric information each branch retains.

• Diffuse walls: gather photon deposits or path-trace texels into surface coordinates; reproject the resulting image meshes as the camera moves.
• Specular and dielectric objects: compute a camera-dependent environment lookup and display it as a small textured layer. For a sphere in the box scene, reflection or the analytic refracted exit ray identifies the wall texel to sample.
• Transient lighting: collect independent path batches and bin arrivals into a finite set of time windows. The playback clock selects stored contributions instead of retracing the scene on every scrub.
• Visible photon primitives: retain selected paths, project points, beams or swept geometry, and apply the chosen screen-space reconstruction. Keep the live primitive budget separate from the larger bake budget.
• Export: use images and a compact path set where possible; compare stop-motion copies with keyed reuse before choosing the final .riv or custom .rivx representation.

RIVX names the complete experimental authoring platform. Its native studio, rendering framework and export pipelines address different stages of a scene’s life. Three decisions stay independent: what evaluates the animation or scene, what turns drawing commands into pixels, and what must travel with the exported result. A custom renderer used during authoring does not have to be present in every export.

For imported .riv artwork, the native official and custom drawing routes both use the official Rive core to import and evaluate animation. The custom adapter replaces the drawing boundary and can retain paths, shape identity and auxiliary fields. Scene3D also has a direct rendering route that bypasses the Rive drawing layer for its own geometry and primitives.

Studio is the native authoring application; Draw is the provisional name for its enhanced drawing backend; Suite is the provisional name for a delivered browser combination of Rive, runtime and data. Native .rivx projects remain versioned editable records. These names separate the workspace, rendering machinery and deliverable without renaming the files.

The older RIVX3D viewer draws retained records with custom WebGL2. RIVX3S is a native scene/graph project. RIVXP1 is a photon-path cache. The official-Rive world-path experiment projects retained paths in its host, then updates a bounded pool of ordinary Rive shapes. These routes preserve different information.

Every live card names the drawing runtime, artifact and export action. Browser laboratories with their own export buttons are usable standalone implementations; they are not automatically native desktop menu options.

GPU Canvas is more than a shader behind a Rive interface. Its image participates in the normal Rive draw stream; its color view can feed subsequent GPU passes. The Canvas API can render Rive content into a texture, and nested passes have an execution order defined by the runtime. A Rive → texture → shader → Rive composition is therefore a supported architectural pattern.

This matters as the instrument becomes more interlaced: several GPU canvases, vector masks, transformed children, shared controls and dependent passes should agree on state, ordering and lifecycle. In an official document, that composition is authored inside Rive. An external hybrid can implement selected equivalent behavior, but its host must own texture handoff, parameter and clock synchronization, coordinate conversion, input routing and resource lifetime.

The paired instruments on this page demonstrate matching selected controls and visual models. They do not establish universal GPU Canvas parity. The native Browser delivery recipe currently layers official Rive underlay/overlay around a retained renderer; that recipe alone is not an arbitrary texture-feedback graph.

The return-to-vector route remains valuable: isocurves, hatching, projected beams and fitted marks are an aesthetic and representation choice. Ordinary .riv playback can carry that drawing without an embedded shader. GPU Canvas expands the available implementations while leaving the cost and meaning of the chosen representation visible.

For a loaded RIVX3S scene, open 3D_new → Tools → Scene node editor. Panels → 3D scene node editor and Export → Open scene nodes reach the same graph. System graph is the backend-routing diagram; it is a separate view. Re-entering 3D_new preserves the loaded scene.

For the unified retained-cloud browser suite: open RIVX Studio → Delivery → Browser delivery. Choose Caustic splat room, Transient fog beams or Relay rings, then press Prepare + generate suite. The action opens Photon Lab, produces a deterministic source population and writes every browser artifact together. If Photon Lab already contains a useful trace, Generate browser-viewable suite now exports that source directly.

For official Rive path replay: open 3D_new → Tools → Export / browser delivery → Browser: live paths through official Rive. Choose an evaluated TracedPaths node, output folder and path budget. The Web replay toolbar popup reaches the same controls. Serve the generated folder over HTTP, then open index.html; it includes its official Rive runtime locally.

For the editable native workspace: Export → Save scene + node graph (.rivx) saves RIVX3S. This retains the scene, graph, camera and supported parameters for the native engine; it does not generate a general scene-graph HTML player. Referenced external assets still need to accompany the document.

Export-New now has an actual generation path rather than a collection of recipe controls. Prepare + generate suite loads a reproducible Photon Lab fixture, waits for its first traced population, and exports automatically. The ordinary Generate browser-viewable suite now button remains visible while the source is unavailable, with a readiness message explaining what is missing.

The suite is intentionally redundant: the offline HTML is a direct retained-data viewer, the hybrid HTML composes retained WebGL with official Rive layers, the two .riv files can be inspected independently, and the receipt records the renderer and stacking order. This makes the result easier to test and prevents a custom viewer from being described as official .riv playback.

The hourglass is retained geometry, not a sequence of rendered volume frames. Each vertex carries source optical travel length, including refractive index × distance through glass. The GPU interpolates this clock across the finite sheets and evaluates a soft Gaussian time window. Moving the window changes the illuminated portion without retracing or rebaking.

The receiver does not require a bake either. Direct splats evaluate the same gate at every hit. The atlas instead accumulates their spatial kernels into a surface chart and adjacent time layers, then samples the gate at the layers’ stored times. This exchanges per-hit work for texture lookup and introduces spatial and temporal discretization.

The two receiver modes should usually agree. Fine sampling and the common beauty reconstruction can make a switch almost invisible. The receiver-only comparison places both results in the same chart before blur and tone mapping, so the approximation can be inspected without inventing a stylistic difference. Narrower windows expose temporal sampling more strongly.

This is a finite fixed-scene experiment. Continuous clock evaluation does not make the retained angular mesh exact, nor does a larger atlas prove convergence or a speedup. The schematic uses ray legs recovered from the retained sheets and glass guide segments; its nominal Rive ray interval and the soft Gaussian shading window are explicitly distinguished.

The asymptotic counts are a design comparison, not a measured speedup. Visibility, texture resolution, compression and overdraw determine actual cost. A receiving surface is lower-dimensional than the scattering volume, which is why treating both as the same splat cloud is often wasteful.

The native Wavefront solver uses image-source constructions for planar paths and Snell-traced meridians through a sphere with accumulated optical distance. Revolving those meridians gives an axisymmetric refracted front; another path builds a more general traced ray grid. This is geometric optics with restricted path families, not a full wave-equation simulation.

The browser’s time-sliced ball starts at a medium collision V with a retained prefix clock τV. A source-time shell satisfies |x−V| = τ−τV in the homogeneous exterior; adding a straight homogeneous detector leg gives |x−V|+|x−C| = τ−τV. The latter is an ellipsoid with two foci. A finite kernel thickens the surface; occlusion and additional interfaces can clip or invalidate this simple form.

The moving hourglass instead follows source rays through both refractive interfaces and selects their stored optical clock. It offers a complementary live view of bent and focusing fronts. Its finite angular sheets are a browser approximation, distinct from the native analytical evaluator and from the medium-anchor construction.

Native strategy 20 has a correlated raster gather that calls the same exact crossing evaluator; its use of rasterization is not itself a reason to call it biased. A separate fast-preview setting deliberately draws finite sheets. Strategy 32 extends the construction to finite triangular charts and more general refractive geometry.

This browser implementation is a bounded finite-sheet experiment inspired by the fast preview. It uses angular quadrature, interpolated optical lengths, a clamped grazing denominator, capped density and display exposure. It therefore has bias and finite-tessellation error. Analytical sphere intersections and Snell/Fresnel transmission are real computations, but the displayed glass shell, attenuation and caustic brightness do not establish full path-tracer equivalence.

That division is useful for RIVX: GPU triangles carry the dense field, while Rive supplies scene-aware contours and interaction cues. The work can remain visually responsive without attempting to turn every transport sample into an individual Rive object.

The live studies make the representation visible. Native paired probes measure rendering costs under controlled workloads. Together they guide authoring choices; they are not a claim that a vector approximation is always faster than its shader or image source.

The pinned renderer reserves finite path and contour IDs and bounds its tessellation-resource texture. Ordinary overflow requests another logical flush; a single draw or clip stack that still cannot fit is rejected. There is no universal safe count for the entire scene. Thousands of tiny disjoint paths and thousands of overlapping feathered paths are different workloads.

On the custom backend, clipping and feather repeatedly touch per-shape coverage buffers. Cached geometry and paint-independent feather coverage can help, but retain scaffolding and memory costs. On the web, blend-mode copies and the selected runtime backend add further constraints.

Keep semantic outlines, shading regions, hatches and annotations as vectors. Retain full geometry-derived contours where available; contours extracted from a low-resolution buffer cannot recover information that buffer never contained. Use textures or specialized accumulation for dense radiance, then compose the useful vector layer with it.

This is consistent with Rive’s own guidance on mixing vector and raster. Current official documentation also introduces GPU Canvas for 3D, so the limits of this project’s exporter should not be presented as permanent limits of every future .riv runtime. Compatibility must name the actual container, feature subset and runtime.

A diffuse surface bake can be reused across camera poses while its geometry and lighting remain fixed. A mirror or refractive appearance image depends on the eye, so an orbit may need a new asset per sampled pose. Illumination varying with the transport clock adds another axis: the export must retain time samples or recompute a representation in a custom player.

This produces a practical cost decomposition. Shared surface images mainly cost texture storage and projected mesh data. View-dependent images scale with the authored views. Vector patterns cost paths and their changing geometry; a dense cloud mapped into runtime objects costs components and per-frame evaluation. There is no single export-quality slider that controls all of these terms.

Replacing an appearance layer with a cheaper representation can reduce one term without improving the others. The export tiers make those tradeoffs explicit so a compact .riv snapshot, an authored orbit and a retained 3D artifact can each have a clear purpose.

The scene layer supplies geometry, masks and material identities. The GPU layer evaluates direct illumination, visibility and a compact glass response. The Rive layer draws contours, the light cue and stylized caustic marks. Those marks derive from the scene and controller rather than from GPU pixel readback; they are semantic overlays, not reconstructed light transport.

The portable artifact contains 25 light poses over a 200-degree arc, separated into five named regions, plus 171 vector marks. Its 640 × 420 images occupy an approximately 8.1 MiB .riv. This first export is a bounded sample bake, not a compact analytical lighting basis: camera and baked materials stay fixed, and the light timeline steps between samples.

The live fixture uses Schlick Fresnel, Beer tint, two sphere refractions and one reflected ray. Its caustic is an artistic lobe; it does not compute multiple-bounce global illumination. Its small retained-scene schema is specific to this study, not a universal loader for native .rivx files.

The loader identifies the six-byte format marker and dispatches to the matching reader. These containers are not ordinary RIVE data with an optional appended payload. Some can reconstruct ordinary drawables for a Rive backend; others require a custom primitive renderer or the native engine. That distinction applies even when all filenames end in .rivx.

The scene and pipeline formats retain editable configuration. The 2D Gaussian format stores a compact field consumed by an instanced custom path. The retained 3D player recomputes projection from world records in WebGL2, while the native replay format has a different compute requirement. A browser player for one container is not evidence that every sibling is browser-compatible.

The retained 3D viewer currently draws complete recorded rings; it does not perform fresh general occluder clipping for every camera position. Its time gates and primitive profiles are the viewer’s declared operations. The ordinary Rive preview uses the official runtime and its network-loaded dependency, whereas the exported retained-3D HTML packages its player content for standalone viewing.

A compact scene description needs the scene engine that interprets it. A photon replay may require compute resources beyond the WebGL2 viewer. Compatibility must therefore be stated per container and export route, rather than promised from the shared filename suffix.

The most useful workflow pairs each conversion with a specific observable. A photon kernel can be checked by summing its linear texel contributions; a trained cloud by held-out target views; a vector conversion by the imported player’s rendered image and object tree; a temporal export by its effective compositing weights. None of these checks substitutes for all of the others.

The source record contains earlier experiments, later corrections and queued designs. The detailed explanations here use the current engine/export/estimator notes together with the implementation and named presets. Earlier blanket timing claims, proposed automatic estimator dispatch and general clipping or transport features not supplied by the current player are not promoted into present capabilities.

The unresolved cases remain useful research directions: a released primitive needs a valid measure and domain; a finite spatial estimator needs a convergence check beyond total mass; an export needs a bounded representation error and an actual player test. Those are concrete next steps attached to working systems rather than additional unrelated effects.

Performance evidence follows the same discipline. The current engine notes supersede earlier broad timing claims and separate CPU submission, GPU elapsed time and wall time. Paired measurements account for build configuration and machine state. The result is a system whose limitations guide representation choices: use the existing runtime where its vocabulary and batching fit, retain a custom representation where the missing information is essential.

A lighting control defines more than another image: a small change reveals which pixels respond, in which direction and by how much. This browser experiment displays a signed central difference of linear luminance with respect to light angle. Cyan marks a decrease, orange an increase, and a selectable step exposes the finite width of hard-shadow changes.

The same bounded forward model can recover selected light and appearance parameters from target pixels. Choose ceramic, metal or lacquer, then add mokume bands, woven inlay or porcelain waves. Solve for light angle, power, roughness, bump relief, tint and pattern contrast. Relief changes shading normals; the sphere silhouettes remain fixed.

Compound surfaces connect to LTC’s material experiments; the image-residual loop connects to the portfolio’s inverse-design work. The research project hosts this same executable study. Leave Live update enabled in the Rive drawing, then orbit, relight or change the material: the host rebuilds actual ordinary Rive polygons as you edit. Export saves the current projected drawing; the solver and 3D scene remain authoring operations.

The differential view adds a matching CPU/GLSL diffuse and GGX response, known ceramic/metal/lacquer materials, procedural colour patterns and analytic bump normals. The separate surface-bake comparison preserves its simpler Lambertian irradiance semantics. Bump relief changes shading normals, not geometry, silhouettes or visibility.

The sensitivity image central-differences linear luminance with respect to light angle before tone mapping. The inverse solver receives sampled linear target colours and estimates the selected bounded scalars. It uses a measured angle survey, damped Gauss–Newton and residual-tested backtracking. Material and pattern family remain known discrete choices; pattern contrast is a scalar, not a recovered arbitrary texture.

Accepted steps become smooth visual transitions. Instant solve skips that presentation delay and reports measured numerical work. Visibility and sharp highlights still make the objective nonconvex. This scene does not establish general material, geometry or full-texture recovery. The paired Inverse Render Lab route uses the same model and solver, so the research demonstration grows with this showcase.

The project joins three kinds of work: authoring richer scenes, extending how they are drawn, and delivering the result through an appropriate player. The scene may contain 3D motion, light transport, soft fields or temporal effects. The presentation may keep live computation, express it as Rive curves and regions, or bake selected dependencies into images and keys. Choosing that boundary is the common task across the platform.

The work began with a 3D Rive scripting prototype: more convincing than expected, but expensive when many samples and drawing updates ran through the script layer. It led to two complementary tools: a desktop authoring studio and an enhanced drawing backend. Returning the result to ordinary Rive then became a representation problem: reuse projected motion as keys, reconstruct illumination with surfaces or curves, and express soft fields with controlled marks.

GPU Canvas adds another way to explore these ideas, with live shader evaluation inside the document. The ordinary-vector experiments keep asking a different question: how much of a shaded scene can be expressed through paths, fills and animation? Rebuilding an image from that smaller vocabulary reveals patterns, approximations and drawing styles that are interesting in their own right.

Following these questions produced several working forms: ordinary .riv exports, signed GPU Canvas instruments and specialized browser viewers. Each preserves a different part of the scene. Their differences are part of what the project explores.

The same illuminated room can be stored as six surface images, a collection of Gaussian primitives, a sequence of projected vector poses, or a retained 3D record. These alternatives differ in what can still change after export. Moving the camera over a diffuse lightmap reuses surface illumination; moving around an already projected drawing cannot reveal a newly visible surface. A mirror image depends on the eye position even when the room and light remain fixed.

The native application is the authoring and research workbench. Ordinary .riv files carry a representable drawing or authored animation. GPU Canvas .riv files carry supported shader computation inside a Rive document. A hybrid browser suite carries its own additional runtime and scene data. Native .rivx project files are a separate family of editable records; the suffix does not promise a universal browser player.

A diagram may need controllable contours; a product page may need a small authored orbit; a rendering study may need free camera and time inspection. Those needs suggest different retained data and players. Vector contours can scale cleanly; dense radiance stored in a texture keeps its finite pixel resolution.

An ordinary .riv can still contain native animation, state machines and parameter interaction. A bake constrains the scene dependencies it discarded; it does not mean “no extra backend, no interaction.” View-dependent glass stored over one camera orbit cannot answer an arbitrary new view, whereas keyed contours can still be recoloured or restyled.

The original competition work explored a small 3D world using the host’s drawing vocabulary. Repeated geometry updates, many soft contributions and transport work made that execution path unsuitable for the intended scene budget. The recordings preserve the prototype’s behavior and authoring controls; the native laboratory then exposes the renderer and primitive costs directly.

The direct C++ route keeps the existing Rive animation runtime while supplying a renderer and factory implementation. This separates loading and animation from drawing. It also makes it possible to retain geometry-derived fields, batch specialized primitives, and inspect the official and custom backends under the same application controls.

Discovering GPU Canvas changed where a live computation can be delivered. It did not erase the questions that motivated the renderer and export work: which data is available to an effect, which approximation preserves the intended appearance, and which interactions survive in the chosen player.

A fresh native pressure probe passed eight structural checks; the controlled O0/O2 renderer comparison comes from the recorded paired study. Export tests cover official import, property replay, topology and paint-order fallback. Those tests do not supply a mobile frame-rate guarantee or a new equal-error transport benchmark.

The low-overhead world-path experiment deliberately keeps display work bounded. Its result tests whether useful interactive structure can survive as a small Rive drawing. It does not replace the native scene engine or claim to reproduce the complete shaded scene.

RIVX explores authoring, drawing and representation around official Rive. Its evidence is the behavior of the working experiments and the measured tradeoffs between their outputs. Each result can be judged at that scope.