Skip to content
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

Open
dhardy opened this issue Sep 22, 2019 · 2 comments
Open

MechanicalWorld and migration from v0.11 #233

dhardy opened this issue Sep 22, 2019 · 2 comments

Comments

@dhardy
Copy link
Contributor

dhardy commented Sep 22, 2019

I notice that DefaultMechanicalWorld is not really a replacement for nphyics3d::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)?

@sebcrozet
Copy link
Member

Hi! I'd prefer not to add a structure like the old World because of the added maintenance cost. The main differences between the new MechanicalWorld and the old one is that all features that belong to its other components (GeometricalWorld, body, collider sets, etc.) have to be accessed on those components directly now.

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.

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.

The reason why they are no separate is for two reasons:

  • Ease of interaction with other systems (like game engines) that may provide their own storage for all those components.
  • For removing limitation (due to borrowing rules) that prevented the user of nphysics from, e.g., get mutable access to bodies and colliders while iterating on the list of contacts.

@dhardy
Copy link
Contributor Author

dhardy commented Oct 1, 2019

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 World definition and the sub-set of methods I needed:

/// 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 Window struct (which ideally wouldn't embed the scene for similar reasons to the above) and use the underlying components directly (Canvas, SceneNode etc.).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants