Call MeshRayCast cast_ray without mut

[powei-lin]

Objective

• cast_ray always clean up the storage first without checking anything. So I don't see why it needs to store those values.

        self.hits.clear();
        self.culled_list.clear();
        self.output.clear();

• The benefit of making cast_ray without &mut self is that we can easily parallelize this call. For example I was trying to simulate lidar. The original implementation makes the bottleneck of simulating thousands of ray cast on one CPU thread because MeshRayCast is SystemParam and it requires &mut self to call cast_ray. After removing &mut self you can easily use it with rayon par_iter.

Solution

• Remove &mut self from cast_ray.

Testing

• Did you test these changes? If so, how? It's a simple change. Need to fix the api and example. All the unit test still passed.
• Are there any parts that need more testing?
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[hukasu]

it is to cache the capacity of the vectors, if every call to cast_ray needs to allocate a 500 items long vector it would be really slow

[powei-lin]

@hukasu It's actually slower if you make it require &mut self. Cast 1000 rays in parallel is way faster than saving the time of allocating vectors but only doing it in one thread. If you have a better suggestion I can change the implementation. But I hope calling cast_ray doesn't require &mut self

[hukasu]

did you already bench it to be affirming that?

[powei-lin]

I'm testing on a m4 mac mini base model. It has 4 large cores and 6 small cores.

Each ray cast has ~110 aabb hits. There are 1200 rays. I'm using cargo run -r with opt-level = 3
The original implementation took 2_696_871 micro seconds per frame.
The new implementation with par_iter took 466_937 micro seconds per frame.

[atlv24]

thread_local cache could be the best of both worlds

[Vrixyz]

Nit: Alternatively, cast_ray could take into parameters the offending structures needed for its call, so we can instantiate as much as we need (1 per thread) and reuse them, rather than reallocating them each time but in parallel.

As there has been a positive benchmark for stress test, I'm approving.