Physics
Physics is opt-in and mostly automatic: the floor is solid without you asking, and things you mark as dynamic fall. The rules below explain the two or three cases where it does not behave the way people expect.
What counts as solid
Something is solid if you gave it a rigid body, or if it has a shape and nothing above it already claimed one. The floor stops you because it is a floor — you do not have to remember to mark it.
Working up from an object:
| The object has… | Result |
|---|---|
| a rigid body | it is its own body |
| a rigid body set to none | nothing here is solid, including its children |
| a collider — even an invisible one | solid |
| geometry, and it is visible | solid |
| geometry, but it is hidden | not solid |
| none of the above (a group, a light) | not solid |
Two things follow from this, and both are useful:
A collider means you meant it, so it stays solid while invisible. That is exactly how you build an invisible wall: a collider and no geometry. Visitors bump into nothing at all.
Geometry is only solid while you can see it. Hide a decorative shape and it stops blocking things too.
Once a shape has joined a larger body, it stays in it even when hidden. To take it out, remove the object or set its rigid body to none.
Where collision shapes come from
Give an object a collider and that is what it uses. Without one, the engine works a shape out from the geometry:
| Geometry | You get |
|---|---|
| box, sphere, cylinder, capsule, cone | the matching shape |
| the three polyhedra | an exact hull |
| plane, circle, ring, triangle | a thin double-sided slab |
| torus | a ring of overlapping spheres |
| extrude, lathe | an exact mesh shape |
| an imported 3D model | nothing — see below |
This is the most common physics surprise by a wide margin. Drop a GLB into a scene, mark it dynamic, and it falls through the world. Add a collider — a box or a capsule is nearly always the right answer — and it behaves.
A mesh shape (from extrude, lathe or imported geometry) is fine for a static floor or wall. On anything that moves it passes through things and jitters. Use a box, sphere, capsule or cylinder instead — simple shapes are also far faster.
Scale is baked into the shape, so scaling an object scales what it collides with.
Moving a physics body
Physics owns where a dynamic body is, and writes over your change on the next step. It looks like the editor is ignoring you.
Move it with an impulse or a force, and put it somewhere with a teleport — respawns, checkpoints, "back to the start".
From a script that is ctx.physics.teleport(...) and ctx.physics.applyImpulse(...) —
see the ctx reference. If you want a walking character,
game controls handle all of this for you.
Reading how fast something is going is cheap and lags by about a frame — perfect for "am I moving?", not for exact maths.
World settings
Gravity, default friction, bounciness and solver quality are set per project and can be overridden per space. Changes apply immediately — no restart.
An individual body can override friction and bounciness; leave them alone and it inherits the world's.
Collisions
When two things touch, both are told: an on-collide event fires on each, and each learns what
it hit. In an event you can narrow that to specific objects, or leave it open.
Unlike a tap, it fires only on the objects that actually touched. Put the event on the thing doing the colliding.
When physics runs at all
| Where | Physics? |
|---|---|
| Player (web) | yes |
| ARClip app (mobile) | yes |
| Editor | no — nothing falls while you are working |
Even in the player, the engine only starts physics when a scene needs it: something dynamic or kinematic, game controls, or a body plus a script. A scene of static scenery does not pay for it — on the web that saves your visitors a multi-megabyte download.
The check is live, so a ball a script creates mid-session brings physics up for itself.
Next: Lights — and what can animate smoothly.