avian3d/lib.rs
1//! 
2//!
3//! **Avian** is an ECS-driven 2D and 3D physics engine for the [Bevy game engine](https://bevyengine.org/).
4//!
5//! Check out the [GitHub repository](https://github.com/avianphysics/avian)
6//! for more information about the design, read the [Getting Started](#getting-started)
7//! guide below to get up to speed, and take a look at the [Table of Contents](#table-of-contents)
8//! for an overview of the engine's features and their documentation.
9//!
10//! You can also check out the [FAQ](#frequently-asked-questions), and if you encounter
11//! any further problems, consider saying hello on the [Bevy Discord](https://discord.gg/bevy)!
12//!
13//! # Getting Started
14//!
15//! This short guide should help you get started with Avian.
16//!
17//! ## Add the Dependency
18//!
19//! First, add `avian2d` or `avian3d` to the dependencies in your `Cargo.toml`:
20//!
21//! ```toml
22//! # For 2D applications:
23//! [dependencies]
24//! avian2d = "0.6"
25//!
26//! # For 3D applications:
27//! [dependencies]
28//! avian3d = "0.6"
29//!
30//! # If you want to use the most up-to-date version, you can follow the main branch:
31//! [dependencies]
32//! avian3d = { git = "https://github.com/avianphysics/avian", branch = "main" }
33//! ```
34//!
35//! You can specify features by disabling the default features and manually adding
36//! the feature flags you want:
37//!
38//! ```toml
39//! [dependencies]
40//! # Add 3D Avian with double-precision floating point numbers.
41//! # `parry-f64` enables collision detection using Parry.
42//! avian3d = { version = "0.6", default-features = false, features = ["3d", "f64", "parry-f64", "xpbd_joints"] }
43//! ```
44//!
45//! ## Feature Flags
46//!
47//! | Feature | Description | Default feature |
48//! | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
49//! | `2d` | Enables 2D physics. Incompatible with `3d`. | Yes (`avian2d`) |
50//! | `3d` | Enables 3D physics. Incompatible with `2d`. | Yes (`avian3d`) |
51//! | `f32` | Enables `f32` precision for physics. Incompatible with `f64`. | Yes |
52//! | `f64` | Enables `f64` precision for physics. Incompatible with `f32`. | No |
53//! | `default-collider` | Enables the default [`Collider`]. Required for [spatial queries](spatial_query). Requires either the `parry-f32` or `parry-f64` feature. | Yes |
54//! | `parry-f32` | Enables the `f32` version of the Parry collision detection library. Also enables the `default-collider` feature. | Yes |
55//! | `parry-f64` | Enables the `f64` version of the Parry collision detection library. Also enables the `default-collider` feature. | No |
56//! | `xpbd_joints` | Enables support for [XPBD joints](dynamics::solver::xpbd). . | Yes |
57#![cfg_attr(
58 feature = "3d",
59 doc = "| `collider-from-mesh` | Allows you to create [`Collider`]s from `Mesh`es. | Yes |"
60)]
61//! | `bevy_scene` | Enables [`ColliderConstructorHierarchy`] to wait until a [`Scene`] has loaded before processing it. | Yes |
62//! | `bevy_picking` | Enables physics picking support for [`bevy_picking`] using the [`PhysicsPickingPlugin`]. The plugin must be added separately. | Yes |
63//! | `bevy_diagnostic` | Enables writing [physics diagnostics] to the [`DiagnosticsStore`] with the [`PhysicsDiagnosticsPlugin`]. The plugin must be added separately. | No |
64//! | `diagnostic_ui` | Enables [physics diagnostics] UI for performance timers and counters using the [`PhysicsDiagnosticsUiPlugin`]. The plugin must be added separately. | No |
65//! | `debug-plugin` | Enables physics debug rendering using the [`PhysicsDebugPlugin`]. The plugin must be added separately. | Yes |
66//! | `enhanced-determinism` | Enables cross-platform deterministic math, improving determinism across architectures at a small performance cost. | No |
67//! | `parallel` | Enables some extra multithreading, which improves performance for larger simulations but can add some overhead for smaller ones. | Yes |
68//! | `simd` | Enables [SIMD] optimizations. | No |
69//! | `serialize` | Enables support for serialization and deserialization using Serde. | No |
70//! | `validate` | Enables additional correctness checks and validation at the cost of worse performance. | No |
71//!
72//! [`bevy_picking`]: bevy::picking
73//! [physics diagnostics]: diagnostics
74//! [`DiagnosticsStore`]: bevy::diagnostic::DiagnosticsStore
75//! [SIMD]: https://en.wikipedia.org/wiki/Single_instruction,_multiple_data
76//!
77//! ## Add the Plugins
78//!
79//! Avian is designed to be very modular. It is built from several [plugins](PhysicsPlugins) that
80//! manage different parts of the engine. These plugins can be easily initialized and configured through
81//! the [`PhysicsPlugins`] plugin group.
82//!
83//! ```no_run
84#![cfg_attr(feature = "2d", doc = "use avian2d::prelude::*;")]
85#![cfg_attr(feature = "3d", doc = "use avian3d::prelude::*;")]
86//! use bevy::prelude::*;
87//!
88//! fn main() {
89//! App::new()
90//! .add_plugins((DefaultPlugins, PhysicsPlugins::default()))
91//! // ...your other plugins, systems and resources
92//! .run();
93//! }
94//! ```
95//!
96//! Now you can use all of Avian's components and resources to build whatever you want!
97//!
98//! For example, adding a [rigid body](RigidBody) with a [collider](Collider) is as simple as spawning an entity
99//! with the [`RigidBody`] and [`Collider`] components:
100//!
101//! ```
102#![cfg_attr(feature = "2d", doc = "use avian2d::prelude::*;")]
103#![cfg_attr(feature = "3d", doc = "use avian3d::prelude::*;")]
104//! use bevy::prelude::*;
105//!
106//! fn setup(mut commands: Commands) {
107#![cfg_attr(
108 feature = "2d",
109 doc = " commands.spawn((RigidBody::Dynamic, Collider::circle(0.5)));"
110)]
111#![cfg_attr(
112 feature = "3d",
113 doc = " commands.spawn((RigidBody::Dynamic, Collider::sphere(0.5)));"
114)]
115//! }
116//! ```
117//!
118//! You can find lots of [usage examples](https://github.com/avianphysics/avian#more-examples)
119//! in the project's [repository](https://github.com/avianphysics/avian).
120//!
121//! # Table of Contents
122//!
123//! Below is a structured overview of the documentation for the various
124//! features of the engine.
125//!
126//! ## Rigid Body Dynamics
127//!
128//! - [Rigid body types](RigidBody#rigid-body-types)
129//! - [Creating rigid bodies](RigidBody#creation)
130//! - [Movement](RigidBody#movement)
131//! - [Linear](LinearVelocity) and [angular](AngularVelocity) velocity
132//! - [External forces, impulses, and acceleration](dynamics::rigid_body::forces)
133//! - [Gravity] and [gravity scale](GravityScale)
134//! - [Mass properties](dynamics::rigid_body::mass_properties)
135//! - [Linear](LinearDamping) and [angular](AngularDamping) velocity damping
136//! - [Lock translational and rotational axes](LockedAxes)
137//! - [Dominance]
138//! - [Continuous Collision Detection (CCD)](dynamics::ccd)
139//! - [Speculative collision](dynamics::ccd#speculative-collision)
140//! - [Swept CCD](dynamics::ccd#swept-ccd)
141//! - [`Transform` interpolation and extrapolation](PhysicsInterpolationPlugin)
142//! - [Temporarily disabling a rigid body](RigidBodyDisabled)
143//! - [Automatic deactivation with sleeping](Sleeping)
144//!
145//! See the [`dynamics`] module for more details about rigid body dynamics in Avian.
146//!
147//! ## Collision Detection
148//!
149//! - [Colliders](Collider)
150//! - [Creation](Collider#creation)
151//! - [Density](ColliderDensity)
152//! - [Friction] and [restitution](Restitution) (bounciness)
153//! - [Collision layers](CollisionLayers)
154//! - [Sensors](Sensor)
155#![cfg_attr(
156 feature = "3d",
157 doc = "- Generating colliders for meshes and scenes with [`ColliderConstructor`] and [`ColliderConstructorHierarchy`]"
158)]
159//! - [Get colliding entities](CollidingEntities)
160//! - [Collision events](collision#collision-events)
161//! - [Accessing collision data](Collisions)
162//! - [Filtering and modifying contacts with hooks](CollisionHooks)
163//! - [Manual contact queries](collision::collider::contact_query)
164//! - [Temporarily disabling a collider](ColliderDisabled)
165//!
166//! See the [`collision`] module for more details about collision detection and colliders in Avian.
167//!
168//! ## Constraints and Joints
169//!
170//! - [Joints](dynamics::joints)
171//! - [Fixed joint](FixedJoint)
172//! - [Distance joint](DistanceJoint)
173//! - [Prismatic joint](PrismaticJoint)
174//! - [Revolute joint](RevoluteJoint)
175#")]
176//! - [Temporarily disabling a joint](JointDisabled)
177# (advanced)"
180)]
181//!
182//! Joint motors and articulations are not supported yet, but they will be implemented in a future release.
183//!
184//! ## Spatial Queries
185//!
186//! - [Spatial query types](spatial_query)
187//! - [Raycasting](spatial_query#raycasting) and [`RayCaster`]
188//! - [Shapecasting](spatial_query#shapecasting) and [`ShapeCaster`]
189//! - [Point projection](spatial_query#point-projection)
190//! - [Intersection tests](spatial_query#intersection-tests)
191//! - [Spatial query filters](SpatialQueryFilter)
192//! - [The `SpatialQuery` system parameter](SpatialQuery)
193//!
194//! ## Configuration
195//!
196//! - [Gravity]
197//! - [`Transform` interpolation and extrapolation](PhysicsInterpolationPlugin)
198//! - [Physics speed](Physics#physics-speed)
199//! - [Configure simulation fidelity with substeps](SubstepCount)
200//!
201//! ## Debugging and Profiling
202//!
203//! - [Physics debug rendering](PhysicsDebugPlugin)
204//! - [Physics diagnostics](diagnostics)
205//!
206//! ## Scheduling
207//!
208//! - [Schedules and sets](PhysicsSchedulePlugin#schedules-and-sets)
209//! - [`PhysicsSystems`]
210//! - [`PhysicsSchedule`] and [`PhysicsStepSystems`]
211//! - [`SubstepSchedule`]
212//! - [`SolverSystems`] and [`SubstepSolverSystems`](dynamics::solver::schedule::SubstepSolverSystems)
213//! - Many more internal system sets
214//! - [Configure the schedule used for running physics](PhysicsPlugins#custom-schedule)
215//! - [Pausing, resuming and stepping physics](Physics#pausing-resuming-and-stepping-physics)
216//! - [Usage on servers](#can-the-engine-be-used-on-servers)
217//!
218//! ## Architecture
219//!
220//! - [List of plugins and their responsibilities](PhysicsPlugins)
221//! - [Custom plugins](PhysicsPlugins#custom-plugins)
222//!
223//! # Frequently Asked Questions
224//!
225//! - [How does Avian compare to Rapier and bevy_rapier?](#how-does-avian-compare-to-rapier-and-bevy_rapier)
226//! - [Why is nothing happening?](#why-is-nothing-happening)
227//! - [Why is everything moving so slowly?](#why-is-everything-moving-so-slowly)
228//! - [Why did my rigid body suddenly vanish?](#why-did-my-rigid-body-suddenly-vanish)
229//! - [Why is performance so bad?](#why-is-performance-so-bad)
230//! - [Why does movement look choppy?](#why-does-movement-look-choppy)
231//! - [Is there a character controller?](#is-there-a-character-controller)
232//! - [Why are there separate `Position` and `Rotation` components?](#why-are-there-separate-position-and-rotation-components)
233//! - [Can the engine be used on servers?](#can-the-engine-be-used-on-servers)
234//! - [Something else?](#something-else)
235//!
236//! ## How does Avian compare to Rapier and bevy_rapier?
237//!
238//! Rapier is the biggest and most used physics engine in the Rust ecosystem, and it is currently
239//! the most mature and feature-rich option.
240//!
241//! `bevy_rapier` is a great physics integration for Bevy, but it does have several problems:
242//!
243//! - It has to maintain a separate physics world and synchronize a ton of data with Bevy each frame
244//! - The source code is difficult to inspect, as the vast majority of it is glue code and wrappers
245//! for Bevy
246//! - It has poor docs.rs documentation, and the documentation on rapier.rs is often outdated and
247//! missing features
248//! - Overall, it doesn't have a native ECS-like feel
249//!
250//! Avian on the other hand is built *for* Bevy *with* Bevy, and it uses the ECS for both the internals
251//! and the public API. This removes the need for a separate physics world, reduces overhead, and makes
252//! the source code much more approachable and easy to inspect for Bevy users.
253//!
254//! In part thanks to Bevy's modular architecture and the ECS, Avian is also highly composable,
255//! as it consists of several independent plugins and provides lots of options for configuration and extensions,
256//! from [custom schedules](PhysicsPlugins#custom-schedule) and [plugins](PhysicsPlugins#custom-plugins) to
257//! [custom joints](dynamics::joints#custom-joints) and [constraints](dynamics::solver::xpbd#custom-constraints).
258//!
259//! One disadvantage of Avian is that it is still relatively young, so it can have more bugs,
260//! some missing features, and fewer community resources and third party crates. However, it is growing quite
261//! rapidly, and it is already pretty close to feature-parity with Rapier.
262//!
263//! At the end of the day, both engines are solid options. If you are looking for a more mature and tested
264//! physics integration, `bevy_rapier` is the better choice, but if you prefer an engine with less overhead
265//! and a more native Bevy integration, consider using Avian. Their core APIs are also quite similar,
266//! so switching between them shouldn't be too difficult.
267//!
268//! ## Why is nothing happening?
269//!
270//! Make sure you have added the [`PhysicsPlugins`] plugin group and you have given your rigid bodies
271//! a [`RigidBody`] component. See the [getting started](#getting-started) section.
272//!
273//! ## Why is everything moving so slowly?
274//!
275//! If your application is in 2D, you might be using pixels as length units. This will require you to use
276//! larger velocities and forces than you would in 3D. Make sure you set [`Gravity`] to some larger value
277//! as well, because its magnitude is `9.81` by default, which is tiny in pixels.
278//!
279//! ## Why is performance so bad?
280//!
281//! It is highly recommended to enable some optimizations for debug builds, or to run your project
282//! in release mode. This can have over a 100x performance impact in some cases.
283//!
284//! Add the following to your `Cargo.toml` to enable optimizations for debug builds:
285//!
286//! ```toml
287//! # Enable a small amount of optimization in the dev profile.
288//! [profile.dev]
289//! opt-level = 1
290//!
291//! # Enable a large amount of optimization in the dev profile for dependencies.
292//! [profile.dev.package."*"]
293//! opt-level = 3
294//! ```
295//!
296//! You can also further optimize release builds by setting the number of codegen units to `1`,
297//! although this will also increase build times.
298//!
299//! ```toml
300//! [profile.release]
301//! codegen-units = 1
302//! ```
303//!
304//! If you still have performance issues, consider enabling the [`PhysicsDiagnosticsPlugin`]
305//! and [`PhysicsDiagnosticsUiPlugin`] (requires the `diagnostic_ui` feature) to see where time is being spent.
306//! See the [diagnostics](diagnostics) module for more information.
307//!
308//! ## Why does movement look choppy?
309//!
310//! To produce consistent, frame rate independent behavior, physics by default runs
311//! in the [`FixedPostUpdate`] schedule with a fixed timestep, meaning that the time between
312//! physics ticks remains constant. On some frames, physics can either not run at all or run
313//! more than once to catch up to real time. This can lead to visible stutter for movement.
314//!
315//! This stutter can be resolved by *interpolating* or *extrapolating* the positions of physics objects
316//! in between physics ticks. Avian has built-in support for this through the [`PhysicsInterpolationPlugin`],
317//! which is included in the [`PhysicsPlugins`] by default.
318//!
319//! Interpolation can be enabled for an individual entity by adding the [`TransformInterpolation`] component:
320//!
321//! ```
322#![cfg_attr(feature = "2d", doc = "# use avian2d::prelude::*;")]
323#![cfg_attr(feature = "3d", doc = "# use avian3d::prelude::*;")]
324//! # use bevy::prelude::*;
325//! #
326//! fn setup(mut commands: Commands) {
327//! // Enable interpolation for this rigid body.
328//! commands.spawn((
329//! RigidBody::Dynamic,
330//! Transform::default(),
331//! TransformInterpolation,
332//! ));
333//! }
334//! ```
335//!
336//! To make *all* rigid bodies interpolated by default, use [`PhysicsInterpolationPlugin::interpolate_all()`]:
337//!
338//! ```no_run
339#![cfg_attr(feature = "2d", doc = "# use avian2d::prelude::*;")]
340#![cfg_attr(feature = "3d", doc = "# use avian3d::prelude::*;")]
341//! # use bevy::prelude::*;
342//! #
343//! fn main() {
344//! App::new()
345//! .add_plugins(PhysicsPlugins::default().set(PhysicsInterpolationPlugin::interpolate_all()))
346//! // ...
347//! .run();
348//! }
349//! ```
350//!
351//! See the [`PhysicsInterpolationPlugin`] for more information.
352//!
353//! If this does not fix the choppiness, the problem could also be related to system ordering.
354//! If you have a system for camera following, make sure it runs *after* physics,
355//! but *before* Bevy's transform propagation in `PostUpdate`.
356//!
357//! ```
358//! # use bevy::prelude::*;
359//! #
360//! # let mut app = App::new();
361//! #
362//! app.add_systems(
363//! PostUpdate,
364//! camera_follow_player.before(TransformSystems::Propagate),
365//! );
366//! #
367//! # fn camera_follow_player() {}
368//! ```
369//!
370//! ## Is there a character controller?
371//!
372//! Avian does not have a built-in character controller yet. However, it has a [`MoveAndSlide`]
373//! system parameter with utilities for implementing your own kinematic character controllers.
374//! See its documentation for more information.
375//!
376//! There are also some third party character controllers such as [`bevy_ahoy`](https://github.com/janhohenheim/bevy_ahoy)
377//! (kinematic) and [`bevy_tnua`](https://github.com/idanarye/bevy-tnua) (dynamic) that work with Avian.
378//!
379//! For custom character controllers, you can take a look at the
380#![cfg_attr(
381 feature = "2d",
382 doc = "[`dynamic_character_2d`] and [`kinematic_character_2d`] examples to get started."
383)]
384#![cfg_attr(
385 feature = "3d",
386 doc = "[`dynamic_character_3d`] and [`kinematic_character_3d`] examples to get started."
387)]
388//!
389#![cfg_attr(
390 feature = "2d",
391 doc = "[`dynamic_character_2d`]: https://github.com/avianphysics/avian/tree/main/crates/avian2d/examples/dynamic_character_2d
392[`kinematic_character_2d`]: https://github.com/avianphysics/avian/tree/main/crates/avian2d/examples/kinematic_character_2d"
393)]
394#![cfg_attr(
395 feature = "3d",
396 doc = "[`dynamic_character_3d`]: https://github.com/avianphysics/avian/tree/main/crates/avian3d/examples/dynamic_character_3d
397[`kinematic_character_3d`]: https://github.com/avianphysics/avian/tree/main/crates/avian3d/examples/kinematic_character_3d"
398)]
399//!
400//! ## Why are there separate `Position` and `Rotation` components?
401//!
402//! While `Transform` can be used for the vast majority of things, Avian internally
403//! uses separate [`Position`] and [`Rotation`] components. These are automatically
404//! kept in sync by the [`PhysicsTransformPlugin`].
405//!
406//! There are several reasons why the separate components are currently used.
407//!
408//! - Position and rotation should be global from the physics engine's point of view.
409//! - Transform scale and shearing can cause issues and rounding errors in physics.
410//! - Transform hierarchies can be problematic.
411//! - There is no `f64` version of `Transform`.
412//! - There is no 2D version of `Transform` (yet), and having a 2D version can optimize several computations.
413//! - When position and rotation are separate, we can technically have more systems running in parallel.
414//! - Only rigid bodies have rotation, particles typically don't (although we don't make a distinction yet).
415//!
416//! In external projects however, using [`Position`] and [`Rotation`] is only necessary when you
417//! need to manage positions within [`PhysicsSystems::StepSimulation`]. Elsewhere, you should be able to use `Transform`.
418//!
419//! There is also a possibility that we will revisit this if/when Bevy has a `Transform2d` component.
420//! Using `Transform` feels more idiomatic and simple, so it would be nice if it could be used directly
421//! as long as we can get around the drawbacks.
422//!
423//! ## Can the engine be used on servers?
424//!
425//! Yes! Networking often requires running the simulation in a specific schedule, and in Avian it is straightforward
426//! to [set the schedule that runs physics](PhysicsPlugins#custom-schedule) and [configure the timestep](Physics) if needed.
427//! By default, physics runs at a fixed timestep in [`FixedPostUpdate`].
428//!
429//! ## Something else?
430//!
431//! Physics engines are very large and Avian is still young, so stability issues and bugs are to be expected.
432//!
433//! If you encounter issues, please consider first taking a look at the
434//! [issues on GitHub](https://github.com/avianphysics/avian/issues) and
435//! [open a new issue](https://github.com/avianphysics/avian/issues/new) if there already isn't one regarding your problem.
436//!
437//! You can also come and say hello on the [Bevy Discord server](https://discord.com/invite/gMUk5Ph).
438//! There, you can find an Avian Physics topic on the `#ecosystem-crates` channel where you can ask questions.
439//!
440//! # License
441//!
442//! Avian is free and open source. All code in the Avian repository is dual-licensed under either:
443//!
444//! - MIT License ([LICENSE-MIT](https://github.com/avianphysics/avian/blob/main/LICENSE-MIT)
445//! or <http://opensource.org/licenses/MIT>)
446//! - Apache License, Version 2.0 ([LICENSE-APACHE](https://github.com/avianphysics/avian/blob/main/LICENSE-APACHE)
447//! or <http://www.apache.org/licenses/LICENSE-2.0>)
448//!
449//! at your option.
450
451#![doc(
452 html_logo_url = "https://raw.githubusercontent.com/Jondolf/avian/avian/assets/branding/icon.png",
453 html_favicon_url = "https://raw.githubusercontent.com/Jondolf/avian/avian/assets/branding/icon.png"
454)]
455#![allow(
456 unexpected_cfgs,
457 clippy::type_complexity,
458 clippy::too_many_arguments,
459 rustdoc::invalid_rust_codeblocks
460)]
461#![warn(clippy::doc_markdown, missing_docs)]
462
463#[cfg(all(not(feature = "f32"), not(feature = "f64")))]
464compile_error!("either feature \"f32\" or \"f64\" must be enabled");
465
466#[cfg(all(feature = "f32", feature = "f64"))]
467compile_error!("feature \"f32\" and feature \"f64\" cannot be enabled at the same time");
468
469#[cfg(all(not(feature = "2d"), not(feature = "3d")))]
470compile_error!("either feature \"2d\" or \"3d\" must be enabled");
471
472#[cfg(all(feature = "2d", feature = "3d"))]
473compile_error!("feature \"2d\" and feature \"3d\" cannot be enabled at the same time");
474
475#[cfg(all(
476 feature = "default-collider",
477 feature = "f32",
478 not(feature = "parry-f32")
479))]
480compile_error!(
481 "feature \"default-collider\" requires the feature \"parry-f32\" when \"f32\" is enabled"
482);
483
484#[cfg(all(
485 feature = "default-collider",
486 feature = "f64",
487 not(feature = "parry-f64")
488))]
489compile_error!(
490 "feature \"default-collider\" requires the feature \"parry-f64\" when \"f64\" is enabled"
491);
492
493extern crate alloc;
494
495#[cfg(all(feature = "2d", feature = "parry-f32"))]
496pub extern crate parry2d as parry;
497
498#[cfg(all(feature = "2d", feature = "parry-f64"))]
499pub extern crate parry2d_f64 as parry;
500
501#[cfg(all(feature = "3d", feature = "parry-f32"))]
502pub extern crate parry3d as parry;
503
504#[cfg(all(feature = "3d", feature = "parry-f64"))]
505pub extern crate parry3d_f64 as parry;
506
507#[cfg(all(
508 feature = "default-collider",
509 any(feature = "parry-f32", feature = "parry-f64")
510))]
511pub mod character_controller;
512pub mod collider_tree;
513pub mod collision;
514#[cfg(feature = "debug-plugin")]
515pub mod debug_render;
516pub mod diagnostics;
517pub mod dynamics;
518pub mod interpolation;
519pub mod math;
520pub mod physics_transform;
521#[cfg(feature = "bevy_picking")]
522pub mod picking;
523pub mod schedule;
524pub mod spatial_query;
525
526pub mod data_structures;
527
528// TODO: Where should this go?
529pub(crate) mod ancestor_marker;
530
531/// Re-exports common components, bundles, resources, plugins and types.
532pub mod prelude {
533 #[cfg(feature = "debug-plugin")]
534 pub use crate::debug_render::*;
535 #[cfg(feature = "bevy_diagnostic")]
536 pub use crate::diagnostics::PhysicsDiagnosticsPlugin;
537 #[cfg(feature = "diagnostic_ui")]
538 pub use crate::diagnostics::ui::{PhysicsDiagnosticsUiPlugin, PhysicsDiagnosticsUiSettings};
539 #[cfg(feature = "default-collider")]
540 pub(crate) use crate::physics_transform::RotationValue;
541 #[cfg(feature = "bevy_picking")]
542 pub use crate::picking::{
543 PhysicsPickable, PhysicsPickingFilter, PhysicsPickingPlugin, PhysicsPickingSettings,
544 };
545 #[expect(deprecated)]
546 pub use crate::{
547 PhysicsPlugins,
548 collider_tree::{ColliderTreeOptimization, ColliderTreePlugin, TreeOptimizationMode},
549 collision::prelude::*,
550 dynamics::{self, ccd::SpeculativeMargin, prelude::*},
551 interpolation::*,
552 physics_transform::{PhysicsTransformHelper, PhysicsTransformPlugin, Position, Rotation},
553 schedule::{
554 Physics, PhysicsSchedule, PhysicsSchedulePlugin, PhysicsSet, PhysicsStepSet,
555 PhysicsStepSystems, PhysicsSystems, PhysicsTime, Substeps,
556 },
557 spatial_query::{self, *},
558 };
559
560 #[cfg(all(
561 feature = "default-collider",
562 any(feature = "parry-f32", feature = "parry-f64")
563 ))]
564 pub use crate::character_controller::prelude::*;
565 pub(crate) use crate::{
566 diagnostics::AppDiagnosticsExt,
567 math::*,
568 physics_transform::{PreSolveDeltaPosition, PreSolveDeltaRotation},
569 schedule::TimePrecisionAdjusted,
570 };
571 pub use avian_derive::*;
572}
573
574mod utils;
575
576#[cfg(test)]
577mod tests;
578
579use bevy::{
580 app::PluginGroupBuilder,
581 ecs::{intern::Interned, schedule::ScheduleLabel, system::SystemParamItem},
582 prelude::*,
583};
584#[allow(unused_imports)]
585use prelude::*;
586
587/// A plugin group containing Avian's plugins.
588///
589/// # Plugins
590///
591/// By default, the following plugins will be added:
592///
593/// | Plugin | Description |
594/// | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
595/// | [`PhysicsSchedulePlugin`] | Sets up the physics engine by initializing the necessary schedules, sets and resources. |
596/// | [`ColliderBackendPlugin`] | Handles generic collider backend logic, like initializing colliders and AABBs and updating related components. |
597/// | [`ColliderHierarchyPlugin`] | Manages [`ColliderOf`] relationships based on the entity hierarchy. |
598/// | [`ColliderTransformPlugin`] | Propagates and updates transforms for colliders.
599#[cfg_attr(
600 all(feature = "collider-from-mesh", feature = "default-collider"),
601 doc = "| [`ColliderCachePlugin`] | Caches colliders created from meshes. Requires `collider-from-mesh` and `default-collider` features. |"
602)]
603/// | [`ColliderTreePlugin`] | Manages [`ColliderTrees`] for broad phase collision detection and spatial queries. |
604/// | [`BroadPhaseCorePlugin`] | The core [broad phase] plugin that sets up the required resources, system sets, and diagnostics. |
605/// | [`BvhBroadPhasePlugin`] | A [broad phase] plugin that uses a [Bounding Volume Hierarchy (BVH)][BVH] to efficiently find pairs of colliders with overlapping AABBs. |
606/// | [`NarrowPhasePlugin`] | Manages contacts and generates contact constraints. |
607/// | [`SolverPlugins`] | A plugin group for the physics solver's plugins. See the plugin group's documentation for more information. |
608/// | [`JointPlugin`] | A plugin for managing and initializing [joints](dynamics::joints). Does *not* include the actual joint solver. |
609/// | [`MassPropertyPlugin`] | Manages mass properties of dynamic [rigid bodies](RigidBody). |
610/// | [`ForcePlugin`] | Manages and applies external forces, torques, and acceleration for rigid bodies. See the [module-level documentation](dynamics::rigid_body::forces). |
611/// | [`SpatialQueryPlugin`] | Handles spatial queries like [raycasting](spatial_query#raycasting) and [shapecasting](spatial_query#shapecasting). |
612/// | [`PhysicsInterpolationPlugin`] | [`Transform`] interpolation and extrapolation for rigid bodies. |
613/// | [`PhysicsTransformPlugin`] | Manages physics transforms and synchronizes them with [`Transform`]. |
614///
615/// Optional additional plugins include:
616///
617/// | Plugin | Description |
618/// | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
619/// | [`PhysicsPickingPlugin`] | Enables a physics picking backend for [`bevy_picking`](bevy::picking) (only with `bevy_picking` feature enabled). |
620/// | [`PhysicsDebugPlugin`] | Renders physics objects and events like [AABBs](ColliderAabb) and contacts for debugging purposes (only with `debug-plugin` feature enabled). |
621/// | [`PhysicsDiagnosticsPlugin`] | Writes [physics diagnostics](diagnostics) to the [`DiagnosticsStore`] (only with `bevy_diagnostic` feature enabled). |
622/// | [`PhysicsDiagnosticsUiPlugin`] | Displays [physics diagnostics](diagnostics) with a debug UI overlay (only with `diagnostic_ui` feature enabled). |
623///
624/// [`ColliderTrees`]: collider_tree::ColliderTrees
625/// [broad phase]: collision::broad_phase
626/// [BVH]: https://en.wikipedia.org/wiki/Bounding_volume_hierarchy
627/// [`DiagnosticsStore`]: bevy::diagnostic::DiagnosticsStore
628///
629/// Refer to the documentation of the plugins for more information about their responsibilities and implementations.
630///
631/// # World Scale
632///
633/// The [`PhysicsLengthUnit`] resource is a units-per-meter scaling factor
634/// that adjusts the engine's internal properties to the scale of the world.
635/// It is recommended to configure the length unit to match the approximate length
636/// of the average dynamic object in the world to get the best simulation results.
637///
638/// For example, a 2D game might use pixels as units and have an average object size
639/// of around 100 pixels. By setting the length unit to `100.0`, the physics engine
640/// will interpret 100 pixels as 1 meter for internal thresholds, improving stability.
641///
642/// The length unit can be set by inserting the resource like normal,
643/// but it can also be specified through the [`PhysicsPlugins`] plugin group.
644///
645/// ```no_run
646/// # #[cfg(feature = "2d")]
647/// use avian2d::prelude::*;
648/// use bevy::prelude::*;
649///
650/// # #[cfg(feature = "2d")]
651/// fn main() {
652/// App::new()
653/// .add_plugins((
654/// DefaultPlugins,
655/// // A 2D game with 100 pixels per meter
656/// PhysicsPlugins::default().with_length_unit(100.0),
657/// ))
658/// .run();
659/// }
660/// # #[cfg(not(feature = "2d"))]
661/// # fn main() {} // Doc test needs main
662/// ```
663///
664/// # Custom Schedule
665///
666/// You can run the [`PhysicsSchedule`] in any schedule you want by specifying the schedule when adding the plugin group:
667///
668/// ```no_run
669#[cfg_attr(feature = "2d", doc = "use avian2d::prelude::*;")]
670#[cfg_attr(feature = "3d", doc = "use avian3d::prelude::*;")]
671/// use bevy::prelude::*;
672///
673/// fn main() {
674/// App::new()
675/// // Run physics at a variable timestep in `PostUpdate`.
676/// .add_plugins((DefaultPlugins, PhysicsPlugins::new(PostUpdate)))
677/// .run();
678/// }
679/// ```
680pub struct PhysicsPlugins {
681 schedule: Interned<dyn ScheduleLabel>,
682 length_unit: Scalar,
683}
684
685impl PhysicsPlugins {
686 /// Creates a [`PhysicsPlugins`] plugin group using the given schedule for running the [`PhysicsSchedule`].
687 ///
688 /// The default schedule is `FixedPostUpdate`.
689 pub fn new(schedule: impl ScheduleLabel) -> Self {
690 Self {
691 schedule: schedule.intern(),
692 length_unit: 1.0,
693 }
694 }
695
696 /// Adds the given [`CollisionHooks`] for user-defined contact filtering and modification.
697 ///
698 /// Returns a [`PhysicsPluginsWithHooks`] plugin group, which wraps the original [`PhysicsPlugins`],
699 /// and applies the provided hooks. Only one set of collision hooks can be defined per application.
700 pub fn with_collision_hooks<H: CollisionHooks + 'static>(self) -> PhysicsPluginsWithHooks<H>
701 where
702 for<'w, 's> SystemParamItem<'w, 's, H>: CollisionHooks,
703 {
704 PhysicsPluginsWithHooks::<H> {
705 plugins: self,
706 _phantom: core::marker::PhantomData,
707 }
708 }
709
710 /// Sets the value used for the [`PhysicsLengthUnit`], a units-per-meter scaling factor
711 /// that adjusts the engine's internal properties to the scale of the world.
712 ///
713 /// For example, a 2D game might use pixels as units and have an average object size
714 /// of around 100 pixels. By setting the length unit to `100.0`, the physics engine
715 /// will interpret 100 pixels as 1 meter for internal thresholds, improving stability.
716 ///
717 /// Note that this is *not* used to scale forces or any other user-facing inputs or outputs.
718 /// Instead, the value is only used to scale some internal length-based tolerances, such as
719 /// [`SleepingThreshold::linear`] and [`NarrowPhaseConfig::default_speculative_margin`],
720 /// as well as the scale used for [debug rendering](PhysicsDebugPlugin).
721 ///
722 /// Choosing the appropriate length unit can help improve stability and robustness.
723 ///
724 /// # Example
725 ///
726 /// ```no_run
727 /// # #[cfg(feature = "2d")]
728 /// use avian2d::prelude::*;
729 /// use bevy::prelude::*;
730 ///
731 /// # #[cfg(feature = "2d")]
732 /// fn main() {
733 /// App::new()
734 /// .add_plugins((
735 /// DefaultPlugins,
736 /// // A 2D game with 100 pixels per meter
737 /// PhysicsPlugins::default().with_length_unit(100.0),
738 /// ))
739 /// .run();
740 /// }
741 /// # #[cfg(not(feature = "2d"))]
742 /// # fn main() {} // Doc test needs main
743 /// ```
744 pub fn with_length_unit(mut self, unit: Scalar) -> Self {
745 self.length_unit = unit;
746 self
747 }
748}
749
750impl Default for PhysicsPlugins {
751 fn default() -> Self {
752 Self::new(FixedPostUpdate)
753 }
754}
755
756impl PluginGroup for PhysicsPlugins {
757 fn build(self) -> PluginGroupBuilder {
758 let builder = PluginGroupBuilder::start::<Self>()
759 .add(PhysicsSchedulePlugin::new(self.schedule))
760 .add(MassPropertyPlugin::new(self.schedule))
761 .add(ForcePlugin)
762 .add(ColliderHierarchyPlugin)
763 .add(ColliderTransformPlugin::new(self.schedule));
764
765 #[cfg(all(feature = "collider-from-mesh", feature = "default-collider"))]
766 let builder = builder.add(ColliderCachePlugin);
767
768 #[cfg(all(
769 feature = "default-collider",
770 any(feature = "parry-f32", feature = "parry-f64")
771 ))]
772 let builder = builder
773 .add(ColliderBackendPlugin::<Collider>::new(self.schedule))
774 .add(ColliderTreePlugin::<Collider>::default())
775 .add(NarrowPhasePlugin::<Collider>::default());
776
777 // Add solver plugins.
778 let builder = builder.add_group(SolverPlugins::new_with_length_unit(self.length_unit));
779
780 builder
781 .add(BroadPhaseCorePlugin)
782 .add(BvhBroadPhasePlugin::<()>::default())
783 .add(JointPlugin)
784 .add(SpatialQueryPlugin)
785 .add(PhysicsTransformPlugin::new(self.schedule))
786 .add(PhysicsInterpolationPlugin::default())
787 }
788}
789
790// This type is separate from `PhysicsPlugins` to avoid requiring users to use generics
791// like `PhysicsPlugins::<()>::default()` unless they actually want to use collision hooks.
792/// A [`PhysicsPlugins`] plugin group with [`CollisionHooks`] specified.
793pub struct PhysicsPluginsWithHooks<H: CollisionHooks> {
794 plugins: PhysicsPlugins,
795 _phantom: core::marker::PhantomData<H>,
796}
797
798impl<H: CollisionHooks> PhysicsPluginsWithHooks<H> {
799 /// Creates a new [`PhysicsPluginsWithHooks`] plugin group using the given [`CollisionHooks`]
800 /// and schedule for running the [`PhysicsSchedule`].
801 ///
802 /// The default schedule is [`FixedPostUpdate`].
803 pub fn new(schedule: impl ScheduleLabel) -> Self {
804 Self {
805 plugins: PhysicsPlugins::new(schedule),
806 _phantom: core::marker::PhantomData,
807 }
808 }
809
810 /// Sets the value used for the [`PhysicsLengthUnit`], a units-per-meter scaling factor
811 /// that adjusts the engine's internal properties to the scale of the world.
812 ///
813 /// See [`PhysicsPlugins::with_length_unit`] for more information.
814 pub fn with_length_unit(mut self, unit: Scalar) -> Self {
815 self.plugins.length_unit = unit;
816 self
817 }
818}
819
820impl<H: CollisionHooks> Default for PhysicsPluginsWithHooks<H> {
821 fn default() -> Self {
822 Self {
823 plugins: PhysicsPlugins::default(),
824 _phantom: core::marker::PhantomData,
825 }
826 }
827}
828
829impl<H: CollisionHooks + 'static> PluginGroup for PhysicsPluginsWithHooks<H>
830where
831 for<'w, 's> SystemParamItem<'w, 's, H>: CollisionHooks,
832{
833 fn build(self) -> PluginGroupBuilder {
834 // Replace the default collision hooks with the user-defined ones.
835 let builder = self
836 .plugins
837 .build()
838 .disable::<BvhBroadPhasePlugin>()
839 .add(BvhBroadPhasePlugin::<H>::default());
840
841 #[cfg(all(
842 feature = "default-collider",
843 any(feature = "parry-f32", feature = "parry-f64")
844 ))]
845 let builder = builder
846 .disable::<NarrowPhasePlugin<Collider>>()
847 .add(NarrowPhasePlugin::<Collider, H>::default());
848
849 builder
850 }
851}