-
-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MechanicalWorld and migration from v0.11 #233
Comments
Hi! I'd prefer not to add a structure like the old Unfortunately I did not have the time to write a migration guide, though feel free to open issues or ask on discord if you have any difficulty.
The reason why they are no separate is for two reasons:
|
Hi; in the mean-time I was able to work this out and update my code (a fork of the old testbed for 3D) to v0.22 with my own /// A wrapper over collider and mechanical worlds and associated objects.
///
/// This is akin to `nphysics3d::world::World` from 0.11.
pub struct World<N: RealField> {
mechanical_world: DefaultMechanicalWorld<N>,
geometrical_world: DefaultGeometricalWorld<N>,
/// The set of physics bodies
pub bodies: DefaultBodySet<N>,
/// The set of colliders, each attached to a body-part
pub colliders: DefaultColliderSet<N>,
/// Joint constraints on bodies
pub joint_constraints: DefaultJointConstraintSet<N>,
/// Forces acting on bodies
pub force_generators: DefaultForceGeneratorSet<N>,
/// We always have a ground body as a reference.
/// Note that there need not be corresponding colliders or graphics.
pub ground_handle: DefaultBodyHandle,
/// Simulation time point
pub time: N,
} I further modified the code to avoid Kiss3D's If you like I could open a PR vs this repo, but it's not a drop-in replacement for the testbed due to removal of features I didn't need (e.g. fixed cameras) — primarily it shows that a lot cleaner code is possible when fewer generics and esp. run-time options are required. |
I notice that
DefaultMechanicalWorld
is not really a replacement fornphyics3d::world::World
from v0.11 but rather a sub-set. Whatever reason the geometry/collider world, body, collider, joint and force sets are now separate, the examples show that these often do not need to be used separately.Is it worth adding a type akin to the old
World
to wrap all the above (and likely also ease migration from v0.11)?The text was updated successfully, but these errors were encountered: