Rigid-Body Physics in SceneJS
|100 bodies in a single system - Run demo||400 bodies in four systems - Run demo||30 Falling boxes - Run demo|
SceneJS supports rigid-body physics through a collection of special node types which may be inserted into scene graphs to define physical behaviours (ie. coordinate system transformations) for child nodes. Physical simulations may be run across multiple systems, with each system running within an engine on a separate worker thread. This means that when one physics system is overloaded, it will not starve the rendering thread and other physics systems. The physics engines are pluggable - they are JigLibJS by default, but may be easily replaced with alternatives such as AmmoJS, CannonJS, or even with a proxy to a high-performance server-based engine.
Creating a physics body
physics/body node creates a body in a physics system and causes its child nodes to translate and rotate according to the body’s movements and interactions with other bodies.
shape parameter on this node specifies the shape of the body boundary. We’ll describe the different shapes that are available, starting with the
box shape, with which we’ll introduce the general parameters of the node. Then we’ll describe the other shape types, describing only the parameters specific to each of those shape types.
- There is one default physics system per scene
- Each system has its own physics engine (eg. JigLibJS) that runs in its own Web worker
- Using an optional
systemIdproperty on the
physics/bodynode, multiple physics systems may be created per scene
- Note that vectors (size, pos, velocity) on the
geometry/box` are arrays - we’re deprecating object formats for those sort of params.
More body types coming up.
You must ensure that the extents of the
physics/body enclose the space occupied by its child nodes. Ideally, we would do that automatically, expanding and contracting the extents as child nodes are added and removed.
However, the reasons we don’t (re)calculated them automatically are:
- The child nodes might be moving, and thus the boundary would be specified for the extents of their movement, (which again, could be hard to compute in advance, or synchronise the body extents with)
- Whatever creates the
physics/bodynode (eg. a loader, or another custom node type) is likely to be in a position of calculate the extents of child nodes anyway
Although you can specify properties like
mass on individual
physics/body nodes, sometimes you’ll want to share those properties among a group of
Just as we can have a parent
material node wrapping multiple child
geometry nodes, we can have a
physics/material node wrapping multiple child
physics/body nodes, so that the children inherit properties from the parent:
Note that spatial properties like
velocity etc. are not supported on a
physics/material node, because those only make sense on an actual physical body.
Configuring a physics system
physics/system node configures a physics system and may appear anywhere within the scene graph.
We can reconfigure the system any time:
- When the
systemIdis given, the
physics/systemnode will configure that system, creating it first if not existing yet. When
systemIdis absent, the node will configure the scene’s default physics system.
physics/systemnodes are optional - if you create
physics/bodynodes for a
systemId(or the scene’s default system) for which no
physics/systemnode exists in the scene, then that system will just use its default configuration.
There is a collection of convenience nodes, each of which wraps a child
physics/body, which in turn wraps a child geometry primitive node, and configures the extents of the
physics/body to enclose the primitive. These allow you to just create, for example, a teapot with physics behaviours, in one shot:
[More to come..]
Switching physics engines
JigLibJS is the default physics engine, however other supported engines may be selected with a
physicsEngine SceneJS global config. The config will be “jiglibjs” by default, but might also be “cannonjs” or “ammojs” if those are available:
Each supported physics engine will be a RequireJS module within the plugin support library directory, and will export this interface:
- Ability to enable or disable physics systems so they don’t keep running when their bodies are culled from the view (ie. by frustum culling etc)
- Issues tagged ‘physics’
sudo comments powered by Disqus