This isn't technically an issue with the library but I'm wondering about how to use the BVT structure (or indeed the DBVT structure) for retrieving a collection of objects that are intersected by a ray.

I could see from the nrays project that there used to be a cast_ray method on the BVT structure that provided an easy way to do this. Obviously this was built using an older version of ncollide as this no longer seems to exist and I can't see another way to do this.

I had a look at the CollisionWorld and this seems to be closer to what I need, but this is overkill for my use case.

Could someone enlighten me as to the best way to do what I want?

Thanks a lot for any help.

I converted some of the closures over from the old syntax, but I got stuck at

inspection/maybe_as_composite_shape.rs:43:44: 43:48 error: cannot convert to a trait object because trait `shape::composite_shape::CompositeShape` is not object-safe [E0038]
inspection/maybe_as_composite_shape.rs:43                             mem::transmute(self as &CompositeShape<N, P, V, M>)
                                                                                     ^~~~
inspection/maybe_as_composite_shape.rs:30:1: 49:3 note: in expansion of impl_composite_shape_repr!
inspection/maybe_as_composite_shape.rs:51:1: 51:50 note: expansion site
inspection/maybe_as_composite_shape.rs:43:44: 43:48 note: method `map_part_at` has generic type parameters
inspection/maybe_as_composite_shape.rs:43                             mem::transmute(self as &CompositeShape<N, P, V, M>)
                                                                                     ^~~~
inspection/maybe_as_composite_shape.rs:30:1: 49:3 note: in expansion of impl_composite_shape_repr!
inspection/maybe_as_composite_shape.rs:51:1: 51:50 note: expansion site
inspection/maybe_as_composite_shape.rs:43:44: 43:48 note: method `map_transformed_part_at` has generic type parameters
inspection/maybe_as_composite_shape.rs:43                             mem::transmute(self as &CompositeShape<N, P, V, M>)

Since EPA was introduced recently, I have been noticing some strange behavior in my simple 2D simulation, which involves getting contact pairs for two rectangles. Sometimes EPA2 does not converge, or it causes a panic:

thread 'main' panicked at 'assertion failed: neg_dist <= gjk::eps_tol()', ncollide_geometry/query/algorithms/epa2.rs:26:9

I'm using 0881d357a9b59dd0c4829965b6659615692fe6c6 of the send_sync branch.

I've reduced the assertion failure to the following test case. It moves a square cuboid into a long wall cuboid and, if there is a contact, it applies the contact normal to the square's position (in a bit of an arbitrary way). The test case is somewhat convoluted since I don't know what exactly causes the error: https://gist.github.com/leod/f6830274539834098973c6c35527d9d3

I get the error after 174668 iterations of the for loop. Backtrace:

thread 'main' panicked at 'assertion failed: neg_dist <= gjk::eps_tol()', ncollide_geometry/query/algorithms/epa2.rs:26:9
stack backtrace:
..
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: <ncollide_geometry::query::algorithms::epa2::FaceId<N>>::new
             at ./<panic macros>:3
   7: <ncollide_geometry::query::algorithms::epa2::EPA2<P>>::project_origin
             at ./ncollide_geometry/query/algorithms/epa2.rs:202
   8: ncollide_geometry::query::algorithms::epa2::closest_points
             at ./ncollide_geometry/query/algorithms/epa2.rs:292
   9: ncollide_geometry::query::contacts_internal::support_map_against_support_map::support_map_against_support_map_with_params
             at ./ncollide_geometry/query/contacts_internal/support_map_against_support_map.rs:127
  10: <ncollide_pipeline::narrow_phase::contact_generator::support_map_support_map_contact_generator::SupportMapSupportMapContactGenerator<P, M, S> as ncollide_pipeline::narrow_phase::contact_generator::contact_generator::ContactGenerator<P, M>>::update
             at ./ncollide_pipeline/narrow_phase/contact_generator/support_map_support_map_contact_generator.rs:69
  11: <ncollide_pipeline::narrow_phase::contact_generator::incremental_contact_manifold_generator::IncrementalContactManifoldGenerator<P, M, CD>>::add_new_contacts
             at ./ncollide_pipeline/narrow_phase/contact_generator/incremental_contact_manifold_generator.rs:110
  12: <ncollide_pipeline::narrow_phase::contact_generator::incremental_contact_manifold_generator::IncrementalContactManifoldGenerator<P, M, CD> as ncollide_pipeline::narrow_phase::contact_generator::contact_generator::ContactGenerator<P, M>>::update
             at ./ncollide_pipeline/narrow_phase/contact_generator/incremental_contact_manifold_generator.rs:185
  13: <ncollide_pipeline::narrow_phase::contact_generator::one_shot_contact_manifold_generator::OneShotContactManifoldGenerator<P, M, CD> as ncollide_pipeline::narrow_phase::contact_generator::contact_generator::ContactGenerator<P, M>>::update
             at ./ncollide_pipeline/narrow_phase/contact_generator/one_shot_contact_manifold_generator.rs:102
  14: epa_test::main
             at examples/epa_test.rs:29
..

Is this error to be expected due to the way I am using ncollide here, or is it a bug in ncollide?

I've found a cylinder + cuboid that have a distance of 0, proximity is "Intersecting", but no contact is being generated regardless of prediction.

It's somewhat stable on the x axis in that I still get no contact if I vary the x-coords slightly. If I remove 60.0 from the z translations though, it returns a contact.

use nalgebra as na;
use ncollide as nc;
use nalgebra::{Isometry3, Vector3};
use ncollide::shape::{Cuboid, Cylinder};

let cyl = Cylinder::new(0.925, 0.5);
let cyl_at = Isometry3::new(Vector3::new(10.97, 0.925, 61.02), na::zero());
let cuboid = Cuboid::new(Vector3::new(0.05, 0.75, 0.5));
let cuboid_at = Isometry3::new(Vector3::new(11.50, 0.75, 60.5), na::zero());

let distance = nc::query::distance(&cyl_at, &cyl,
                                   &cuboid_at, &cuboid);

let proximity = nc::query::proximity(&cyl_at, &cyl,
                                     &cuboid_at, &cuboid,
                                     0.1);

let contact = nc::query::contact(&cyl_at, &cyl,
                                 &cuboid_at, &cuboid,
                                 10.0);

println!("distance -> {:?}", distance);
println!("proximity -> {:?}", proximity);
println!("contact -> {:?}", contact);

The docs on http://ncollide.org/ seem to be outdated. For example, there seems to be no GeomGeomDispatcher in the project, while the docs clearly mention it here: http://ncollide.org/contact_determination/narrow_phase.html

This is not the full set yet, I'm currently stuck on:

ncollide_utils/optimization.rs:174:39: 174:46 error: cannot apply unary operator `-` to type `V`
ncollide_utils/optimization.rs:174         let mut search_dir = hx.rmul(&-new_dx);
                                                                         ^~~~~~~
ncollide_utils/optimization.rs:179:26: 179:33 error: cannot apply unary operator `-` to type `V`
ncollide_utils/optimization.rs:179             search_dir = -new_dx;
                                                            ^~~~~~~
ncollide_utils/any_private.rs:13:9: 13:24 error: the trait `core::marker::Reflect` is not implemented for the type `T` [E0277]
ncollide_utils/any_private.rs:13         TypeId::of::<T>()
                                         ^~~~~~~~~~~~~~~
ncollide_utils/cov.rs:55:38: 55:55 error: cannot apply unary operator `-` to type `V`
ncollide_utils/cov.rs:55                 *pt = icov * (*pt + (-*center.as_vec()));

This provides a foundation for nphysics to support CCD on custom shapes, and for downstream crates to conveniently compose dispatchers. This requirement is motivated by my work in planetmap to provide collision detection for streaming spherical terrain, which requires close integration with ncollide queries to be efficient, much like heightfields do.

While this could be merged as-is, there's one question I'd like feedback on: should we fold ContactDispatcher and ProximityDispatcher into this trait? A single trait object is more convenient (particularly for composition), and in general anyone seeking to implement a custom shape will probably want to support everything, or at least be fully conscious of any unsupported operations.

Trying to compile a project that indirectly depends on ncollide 0.17.3 (through kiss3d) yields the following compilation failure on rustc 1.34.0-nightly (f66e4697a 2019-02-20) on macOS:

error[E0034]: multiple applicable items in scope
   --> /Users/michaelp/.cargo/registry/src/github.com-1ecc6299db9ec823/ncollide3d-0.17.3/src/shape/shape.rs:103:14
    |
103 |         self.type_id() == TypeId::of::<T>()
    |              ^^^^^^^ multiple `type_id` found
    |
note: candidate #1 is defined in the trait `shape::shape::GetTypeId`
   --> /Users/michaelp/.cargo/registry/src/github.com-1ecc6299db9ec823/ncollide3d-0.17.3/src/shape/shape.rs:158:5
    |
158 |     fn type_id(&self) -> TypeId;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = help: to disambiguate the method call, write `shape::shape::GetTypeId::type_id(&self)` instead
note: candidate #2 is defined in the trait `std::any::Any`
    = help: to disambiguate the method call, write `std::any::Any::type_id(&self)` instead

error: aborting due to previous error

Hi,

It's my first time using ncollide. For now I'm going through the documentation, and try to get the samples running. The contact query example does not work for me. The first assert fails (the prenetration one).

Slightly offsetting the ball (to 1.01, 1.01) makes it work

Hi, I'm trying to use World in a multithreaded app with Mutex, but I can't, because the types involved don't implement Send.

I see that DBVT uses Rc, and I know the usual way to solve that is to switch it to using Arc, but I presume that you don't want to use Arc by default for performance reasons. Is there any other way I can work around this problem?

Replace CollisionGroups

I thought CollisionGroups was way too complex for my taste, so I replaced it by the probably the simplest solution for this problem. Each collider is part of a single collision group, which can or cannot interact with other collision groups. Collision group interaction are determined by the half (triangular) matrix in CollisionWorld.

Add setters and getters for hidden data

Pretty obvious change. If I can't access the data, how am I supposed to use it. If I don't see it, does it even exist? :thinking: Philosophy PR!

Partial serde attempt.

Yeah... That won't work without throwing the Shape trait in the trash and implementing the same thing using an enum.

So this seems to be a bottleneck towards updating the nalgebra version, which is having issues for upstream crates. I noticed that the only thing preventing a direct upgrade was this error

    |     ^^^ use of undeclared crate or module `imp`

Which after some searching, was an issue with the rand crate relying on getrandom and its "js" feature. After following the Indirect Dependencies steps, all of the tests in cargo test passed and the CircleCI passed.

Hopefully this should be a relatively instant PR for updating nalgebra to the latest version.

We have the specific case that we want to collision check groups of objects (cubes, cylinders and meshes) with other groups of objects with the possibility to ignore the collision of specific objects. We want to perform 1000's of queries with dynamic objects at different locations (objects are moving around). We only want proximity's and which objects are colliding, not any contact points etc. We tried the following two things:

1. Using the CollisionWorld. But the event system was not flexible enough for our use case. We also want to know if a repeated collision happened.

2. Creating our own Compound implementation of the group of objects and the corresponding proximity and proximity detectors. And passing a filter function with them. This resulted in a problem with testing out Trimeshes. Because Compound shapes in Compound shapes are not supported, the algorithm became very slow.

What would be the best approach to tackle this problem? Is ncollide the right library for us, or would parry solve this problem better?

Hi, Thanks for this wonderful crate 😄

I'm experiencing a strange behavior in convex hull calculation. I'm creating a convex hull from a set of points (which indeed form a convex shape). The first time the created hull's points are the original points (up to some minor acceptable float precision differences) as expected. But when I take the points of this hull and create a second convex hull from them, the second hull has incorrect points.

An example that reproduces this behavior:

use ncollide3d::math::Point;
use ncollide3d::shape::ConvexHull;

let points = vec![
    Point::new(1., 0., 0.),
    Point::new(-2., 1., 1.),
    Point::new(2., 1., 1.),
    Point::new(2., 0., 2.),
    Point::new(-2., 0., 2.),
    Point::new(1., 1., 0.),
    Point::new(2., 0., 1.),
    Point::new(-2., 0., 1.),
    Point::new(-1., 0., 0.),
    Point::new(-2., 1., 2.),
    Point::new(2., 1., 2.),
    Point::new(-1., 1., 0.),
];

let hull_1 = ConvexHull::try_from_points(&points).unwrap();
println!("hull_1:");
// This prints pretty much the expected points (up to an acceptable float precision):
for point in hull_1.points() {
    println!("({}, {}, {})", point.x, point.y, point.z);
}

let hull_2 = ConvexHull::try_from_points(hull_1.points()).unwrap();
println!("hull_2:");
// This prints incorrect points:
for point in hull_2.points() {
    println!("({}, {}, {})", point.x, point.y, point.z);
}

In the above code, all of the points of hull_2 are completely different from the original point. For example, a point (2, 0.6875000000000018, 3.66666666666667) is somehow added, which is actually pretty far "outside" of the first convex hull.

I expected the second convex hull to have the same points as the first one (again, up to an acceptable minor float precision difference).

Thanks.

Reproduction

use ncollide3d::na::{Point3, Vector3};

fn main() {

	let verts = vec![Point3::new(1.0f32, 1.0, 1.0), Point3::new(-1.0, 1.0, 1.0), Point3::new(-1.0, -1.0, 1.0), Point3::new(1.0, 1.0, 1.0), Point3::new(-1.0, -1.0, 1.0), Point3::new(1.0, -1.0, 1.0), Point3::new(1.0, -1.0, -1.0), Point3::new(1.0, -1.0, 1.0), Point3::new(-1.0, -1.0, 1.0), Point3::new(1.0, -1.0, -1.0), Point3::new(-1.0, -1.0, 1.0), Point3::new(-1.0, -1.0, -1.0), Point3::new(-1.0, -1.0, -1.0), Point3::new(-1.0, -1.0, 1.0), Point3::new(-1.0, 1.0, 1.0), Point3::new(-1.0, -1.0, -1.0), Point3::new(-1.0, 1.0, 1.0), Point3::new(-1.0, 1.0, -1.0), Point3::new(-1.0, 1.0, -1.0), Point3::new(1.0, 1.0, -1.0), Point3::new(1.0, -1.0, -1.0), Point3::new(-1.0, 1.0, -1.0), Point3::new(1.0, -1.0, -1.0), Point3::new(-1.0, -1.0, -1.0), Point3::new(1.0, 1.0, -1.0), Point3::new(1.0, 1.0, 1.0), Point3::new(1.0, -1.0, 1.0), Point3::new(1.0, 1.0, -1.0), Point3::new(1.0, -1.0, 1.0), Point3::new(1.0, -1.0, -1.0), Point3::new(-1.0, 1.0, -1.0), Point3::new(-1.0, 1.0, 1.0), Point3::new(1.0, 1.0, 1.0), Point3::new(-1.0, 1.0, -1.0), Point3::new(1.0, 1.0, 1.0), Point3::new(1.0, 1.0, -1.0)];
	let indices = vec![Point3::new(0usize, 1, 2), Point3::new(3, 4, 5), Point3::new(6, 7, 8), Point3::new(9, 10, 11), Point3::new(12, 13, 14), Point3::new(15, 16, 17), Point3::new(18, 19, 20), Point3::new(21, 22, 23), Point3::new(24, 25, 26), Point3::new(27, 28, 29), Point3::new(30, 31, 32), Point3::new(33, 34, 35)];
	let mesh = ncollide3d::shape::TriMesh::new(verts, indices, None);
	
	let ray = ncollide3d::query::Ray { origin: Point3::new(7.2657557, -6.8810306, 4.931747), dir: Vector3::new(-0.8729342, 0.41952112, -0.24897367) };
	
	let closest = ncollide3d::query::closest_points(
		&ncollide3d::na::Isometry3::identity(),
		&ncollide3d::shape::Segment {
			a: ray.origin,
			b: ray.point_at(99999.9),
		},
		&ncollide3d::na::Isometry3::identity(),
		&mesh,
		2.0
	);
	println!("Closest: {:?}" ,closest);
}

Causes a panic:

thread 'main' panicked at 'The composite shape must not be empty.', /home/col/.cargo/registry/src/github.com-1ecc6299db9ec823/ncollide3d-0.26.1/src/query/closest_points/closest_points_composite_shape_shape.rs:24:10
stack backtrace:
   0:     0x561764860df0 - std::backtrace_rs::backtrace::libunwind::trace::h72c2fb8038f1bbee
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
   1:     0x561764860df0 - std::backtrace_rs::backtrace::trace_unsynchronized::h1e3b084883f1e78c
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/mod.rs:66
   2:     0x561764860df0 - std::sys_common::backtrace::_print_fmt::h3bf6a7ebf7f0394a
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:79
   3:     0x561764860df0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h2e8cb764b7fe02e7
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:58
   4:     0x56176487e00c - core::fmt::write::h7a1184eaee6a8644
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/fmt/mod.rs:1080
   5:     0x56176485efe2 - std::io::Write::write_fmt::haeeb374d93a67eac
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/io/mod.rs:1516
   6:     0x561764862e7d - std::sys_common::backtrace::_print::h1d14a7f6ad632dc8
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:61
   7:     0x561764862e7d - std::sys_common::backtrace::print::h301abac8bb2e3e81
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:48
   8:     0x561764862e7d - std::panicking::default_hook::{{closure}}::hde0cb80358a6920a
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:208
   9:     0x561764862b28 - std::panicking::default_hook::h9b1a691049a0ec8f
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:227
  10:     0x561764863501 - std::panicking::rust_panic_with_hook::h2bdec87b60580584
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:577
  11:     0x5617648630a9 - std::panicking::begin_panic_handler::{{closure}}::h101ca09d9df5db47
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484
  12:     0x56176486125c - std::sys_common::backtrace::__rust_end_short_backtrace::h3bb85654c20113ca
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153
  13:     0x561764863069 - rust_begin_unwind
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
  14:     0x56176487bee1 - core::panicking::panic_fmt::h48c31e1e3d550146
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
  15:     0x56176487bc73 - core::option::expect_failed::hf3f43f1792267e24
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1226
  16:     0x561764807a8f - core::option::Option<T>::expect::h7e919d77919eca17
                               at /home/col/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:346
  17:     0x5617647ff62b - ncollide3d::query::closest_points::closest_points_composite_shape_shape::closest_points_composite_shape_shape::h3089a621794318cc
                               at /home/col/.cargo/registry/src/github.com-1ecc6299db9ec823/ncollide3d-0.26.1/src/query/closest_points/closest_points_composite_shape_shape.rs:22

The graphic here: https://ncollide.org/img/AABB_tree_BVT.svg appears to have an error. It shows that C is not bound in the smaller purple box on the right side of the image. I believe that E should be the leaf entry in the green rect containing the purple rect, but I'm not 100% sure.