Skip to content

Runtime And Playback

Marko Koljancic edited this page Jul 28, 2026 · 1 revision

Home · Solarxy Web · Expressions · Attribute Wrangle

Runtime and playback

Solarxy Web has a scene clock. Press play and anything driven by time recomputes, frame by frame, because the engine is cooking the graph rather than replaying a recording.

The playbar sits under the viewport. It is scene-wide, not per pane: there is one clock. Hide it from the viewport's View menu when you want the frame back.

Control Key
Play / pause Space
Stop Home Rewinds to the start of the range
Step back / forward , and . One frame
Frame The current frame; type or drag to scrub
Start / End The frame range, inclusive
FPS Frames per second
Loop Once, Loop, or Ping-pong

The seconds readout beside the frame field is the value of $T.

Driving something with time

Anywhere you can write an expression or an attribute wrangle program, $T, $F and $FPS are available.

Put an expression on a rotation:

$T * 45

or ripple a surface in a wrangle:

@P = set(@P.x, @P.y + sin(@P.x * 4 + $T) * 0.2, @P.z);

Then press play.

One frame, one tick

A tick advances exactly one frame, rather than however many seconds have passed. That has a consequence worth knowing, because it decides what playback means:

$T is exactly $F / $FPS. There is one number, and seconds is a view of it. Frame 90 always looks the same — on any machine, at any speed, however long the cook took.

The trade is that a heavy scene plays slowly rather than dropping frames. You see every frame, and playback takes as long as the cooking takes. For a modeling tool that is the right way round: you are watching the geometry, not hitting a broadcast deadline. If playback crawls, the fix is upstream — fewer points, a lighter wrangle — and the wrangle's element warning usually tells you where.

The clock enforces this literally: it will not advance while the previous frame is still cooking. So on a scene heavy enough that one frame takes more than one display refresh, the frame counter climbs at half speed (or a third, or a tenth) and the viewport keeps pace with it. What you are watching is a real frame every time, not a counter running ahead of a frozen mesh.

Scrubbing is deliberately not paced this way. Drag the playhead and you get the frame you asked for.

What gets recomputed

Only what depends on time. A tick dirties the nodes whose parameters or wrangle programs actually read $T or $F, and nothing else. A scene with no time in it anywhere costs nothing per frame, so leaving the playbar sitting there is free.

What saves, and what does not

Saved in the scene: the frame range, FPS, loop mode, and the autoplay flag.

Not saved: whether you were playing, and the frame you were parked on.

So a scene always reopens stopped, at the start of its range. That is deliberate. It means a saved file is reproducible — reload it and you get the same picture, not whatever moment the author happened to hit save on. It is also what keeps rendered output and command-line cooks predictable.

Scenes saved before Solarxy 0.8.1 have no clock stored and simply open with the defaults: frames 1 to 240 at 24 fps, looping. Nothing needs converting.

Autoplay

Autoplay is a property of the scene, not of the editor. Turning it on does not make the editor start playing when you open the file — a modeling tool that began animating the moment you opened something would be a nuisance. It is read by a published bundle, where starting on its own is exactly the point.

The turntable is not the clock

The turntable spin in the Display menu rotates the camera. It is a view effect, it is not saved with the scene, and it works whether or not anything is animated. The clock moves the scene; the turntable moves your view of it. They are deliberately separate, so that turning one on never changes what the file means.

See also

Clone this wiki locally