aura
aura
orbit-aura — the comet that runs an element's outline, on every kind of mesh the promo vocabulary can build. One scene per family; the aura params are held constant across a scene so any difference you see comes from the GEOMETRY, not from the settings.
Read the rig's notes
1. solids — geometry primitives with volume: the inflated-shell branch
2. flats — rounded-rect / disc / plane: the hollow SDF rim-card branch
3. paths — <path d="…"> extrusions, including a shape with a hole
4. svg shapes — rect / circle / ellipse / polygon sugar
5. text — glyph planes; every glyph shares ONE card, not one each
6. icons 3d — <icon3d> FBX, a source factory that mounts late
7. devices — <iphone> / <chrome>: rigs that are EMPTY when the fx runs
8. silhouette — the same shapes under shape="silhouette" for comparison
`shape="hull"` (the default) is mesh-only: no render target, no fullscreen
pass, no composer. `shape="silhouette"` masks the element and dilates it in a
composer pass — exact on any outline, but it costs a full extra scene draw
per aura. Scenes 1-7 are hull; scene 8 is the same content under silhouette
so the two can be diffed frame for frame.
THE UI GALLERY (scenes 9-14) — 34 panels, every one of them radius-matched:
9. ui3d panels I six <ui3d> stages, six independent comets
10. ui textures I the same six on <ui> quads mapped through map_from
11. ui3d panels II one stage geometry, swept period / direction / glow
12. ui textures II scene 11's sweep re-run on the rasterised surface
13. ui3d panels III colors="head,mid,tail" palettes
14. side by side both surfaces under the same rig, and the radius rule
15. device overlay ui3d(overlay=screen) — the aura ON a card inside a
phone and a browser screen, which flat <ui> cannot do
16. aura grid nine of those, one choreography, nine aura looks; the
cards never stop moving and the rims stay welded to
them, and the camera drops in on one cell to read it
The two UI surfaces are NOT the same target:
<ui3d> emits its children as REAL meshes in the host scene, so the aura
has geometry to bind to and takes the planar rim-card branch. Each
<ui3d> is its own node, so N panels = N nodes = N independent
auras — nothing is shared between stages. The hull drops every
mesh swallowed by a bigger one and fits ONE card to what survives,
which on a laid-out stage is the content block rather than the
backing card; a stage carrying only a bare card is rimmed edge to
edge. Scene 14 puts both surfaces side by side on one frame.
<ui> renders its children into an offscreen render target and hands
back a TEXTURE. There is no mesh inside it to outline, so the fx
goes on the mesh CARRYING that texture and traces the quad's edge;
the pixels are invisible to it. A <ui> item inside a device screen
is rasterised the same way and cannot carry an aura at all — the
fx warns and renders nothing. Put it on the device, or lift the
one item you want rimmed into a `ui3d(overlay=screen)` on the same
device: an overlay child is a REAL plane surface-anchored on the
glass, in the screen's own mm, so it takes the rim-card branch
like any other mesh. Scene 15 does exactly that on both a phone
and a browser, with the flat <ui> app still painting behind it.
ONE NUMBER TO CARRY AWAY. Both branches read the corner radius off the
element, and a bare quad has square corners — that is all the geometry can
tell the fx. A rounded UI card therefore needs `radius=` in the footprint's
own local units, which is the card's corner radius times the surface's
world-per-pixel. Every panel in scenes 9-14 is a 20px radius on a 520x340
stage mapped to 2.6 x 1.7 world units, i.e. 20 x 0.005 = radius=0.1. Omit it
and the band squares the corners off.
Every param is keyframeable: period, direction, thickness, glow, intensity,
focused, visible_arc, colors / color_a / color_b / color_c, enabled.
Preview: /packages/runtime/index.html?project=promos/primitives/aura/aura.promo- Topic
- effects
- Scenes
- 16
- Kind
- reference rig
//
orbit-aura — the comet that runs an element's outline, on every kind of mesh
the promo vocabulary can build. One scene per family; the aura params are held
constant across a scene so any difference you see comes from the GEOMETRY,
not from the settings.
1. solids — geometry primitives with volume: the inflated-shell branch
2. flats — rounded-rect / disc / plane: the hollow SDF rim-card branch
3. paths — <path d="…"> extrusions, including a shape with a hole
4. svg shapes — rect / circle / ellipse / polygon sugar
5. text — glyph planes; every glyph shares ONE card, not one each
6. icons 3d — <icon3d> FBX, a source factory that mounts late
7. devices — <iphone> / <chrome>: rigs that are EMPTY when the fx runs
8. silhouette — the same shapes under shape="silhouette" for comparison
`shape="hull"` (the default) is mesh-only: no render target, no fullscreen
pass, no composer. `shape="silhouette"` masks the element and dilates it in a
composer pass — exact on any outline, but it costs a full extra scene draw
per aura. Scenes 1-7 are hull; scene 8 is the same content under silhouette
so the two can be diffed frame for frame.
THE UI GALLERY (scenes 9-14) — 34 panels, every one of them radius-matched:
9. ui3d panels I six <ui3d> stages, six independent comets
10. ui textures I the same six on <ui> quads mapped through map_from
11. ui3d panels II one stage geometry, swept period / direction / glow
12. ui textures II scene 11's sweep re-run on the rasterised surface
13. ui3d panels III colors="head,mid,tail" palettes
14. side by side both surfaces under the same rig, and the radius rule
15. device overlay ui3d(overlay=screen) — the aura ON a card inside a
phone and a browser screen, which flat <ui> cannot do
16. aura grid nine of those, one choreography, nine aura looks; the
cards never stop moving and the rims stay welded to
them, and the camera drops in on one cell to read it
The two UI surfaces are NOT the same target:
<ui3d> emits its children as REAL meshes in the host scene, so the aura
has geometry to bind to and takes the planar rim-card branch. Each
<ui3d> is its own node, so N panels = N nodes = N independent
auras — nothing is shared between stages. The hull drops every
mesh swallowed by a bigger one and fits ONE card to what survives,
which on a laid-out stage is the content block rather than the
backing card; a stage carrying only a bare card is rimmed edge to
edge. Scene 14 puts both surfaces side by side on one frame.
<ui> renders its children into an offscreen render target and hands
back a TEXTURE. There is no mesh inside it to outline, so the fx
goes on the mesh CARRYING that texture and traces the quad's edge;
the pixels are invisible to it. A <ui> item inside a device screen
is rasterised the same way and cannot carry an aura at all — the
fx warns and renders nothing. Put it on the device, or lift the
one item you want rimmed into a `ui3d(overlay=screen)` on the same
device: an overlay child is a REAL plane surface-anchored on the
glass, in the screen's own mm, so it takes the rim-card branch
like any other mesh. Scene 15 does exactly that on both a phone
and a browser, with the flat <ui> app still painting behind it.
ONE NUMBER TO CARRY AWAY. Both branches read the corner radius off the
element, and a bare quad has square corners — that is all the geometry can
tell the fx. A rounded UI card therefore needs `radius=` in the footprint's
own local units, which is the card's c