Raycasting by MarekLg · Pull Request #615 · bevyengine/bevy

MarekLg · 2020-10-02T11:24:11Z

Adding this as a draft, as I made some assumptions I am unsure of:

adding this as a separate crate: bevy_physics
Ray::from_mouse_position(..) should be a method of Ray
the example raycast.rs is as simple as possible (e.g. the move mouse.system() could certainly be removed)

Looking forward to your guys feedback 😄

bonsairobo · 2020-12-04T07:44:58Z

I think we probably don't need a separate crate for this. I'd just add a method to the existing Camera type. It could be really simple if the Camera already knew how big the window was, since it's a little bit inconvenient to have to look up the window as well.

Wherever Camera is assigned a window ID, I'd also copy the window size into new fields on the Camera.

As far as where to put the Ray type, probably just in bevy_math would work?

smokku · 2020-12-04T08:07:50Z

I think we probably don't need a separate crate for this. I'd just add a method to the existing Camera type. It could be really simple if the Camera already knew how big the window was, since it's a little bit inconvenient to have to look up the window as well.

Having to access the window is a bit inconvenient, but gets the current information.
Copying this info violates the DRY principle. Windows can be resized.
Encapsulating the window access inside the raycasting method removes the inconvenience.

bonsairobo · 2020-12-04T08:14:26Z

@smokku

Encapsulating the window access inside the raycasting method removes the inconvenience.

How would you? I think right now it's necessary to first query for a Camera and then get the Window via Res<Windows>.

bonsairobo · 2020-12-04T08:16:40Z

Copying this info violates the DRY principle. Windows can be resized.

I was trying to suggest that the size is kept up to date between the Window and Camera. I agree that ideally you wouldn't have to do this. It's just the only thing that came to mind. I'm open to other ideas. Maybe somehow SystemParam could be used to access the window in a convenient way?

smokku · 2020-12-04T08:29:14Z

Copying this info violates the DRY principle. Windows can be resized.

I was trying to suggest that the size is kept up to date between the Window and Camera. I agree that ideally you wouldn't have to do this. It's just the only thing that came to mind. I'm open to other ideas. Maybe somehow SystemParam could be used to access the window in a convenient way?

I mean, right, you have to get the Camera and Windows resources to your system, but then just pass them to the casting method and let the raycaster pull whatever information it wants.

smokku · 2020-12-04T08:54:06Z

crates/bevy_physics/src/d3/ray.rs

+    }
+
+    pub fn from_mouse_position(
+        mouse_position: &Vec2,


Window now has .cursor_position() method. We could add:

pub fn from_window( window: &Window, camera: &Camera, camera_transform: &GlobalTransform, ) -> Self { Self::from_mouse_position(window.cursor_position(), camera, camera_transform) }

Nice. I'll add it.

marko-lazic · 2020-12-08T23:25:13Z

examples/physics/raycast.rs

+
+                let hit = if let Some(plane_hit) = plane_hit {
+                    if let Some(sphere_hit) = sphere_hit {
+                        if plane_hit.t() < sphere_hit.t() {


We have 6 nested (for and if) statements here, that is very complex.

Although I disagree with 6 nested blocks being inherently complex, I agree that this particular instance is unnecessarily verbose and doesn't get the point across. I'm looking for something more elegant but feel free to propose changes where you see fit.

marko-lazic · 2020-12-08T23:29:20Z

crates/bevy_physics/src/d3/intersectors.rs

+use glam::Vec3;
+
+pub struct RayHit {
+    t: f32,


Please consider renaming it to something more meaningful.

That's a good idea!

marko-lazic · 2020-12-08T23:31:02Z

crates/bevy_physics/src/d3/intersectors.rs

+
+impl RayIntersector for Plane {
+    fn intersect_ray(&self, ray: &Ray) -> Option<RayHit> {
+        let d = self.normal().dot(*ray.direction());


Please describe what is this line doing.

It assigns the dot product between the plane normal and the ray direction to the variable d (now changed to denominator). I don't think that needs a comment.

marko-lazic · 2020-12-08T23:32:26Z

crates/bevy_physics/src/d3/intersectors.rs

+        let d = self.normal().dot(*ray.direction());
+        if d.abs() > f32::EPSILON {
+            let t = (*self.center() - *ray.origin()).dot(*self.normal()) / d;
+            if t > 0.0 {


I am guessing the t and d is taken from some formula. We can give it a more verbose name in our code.

I would agree and have changed the names.

marko-lazic · 2020-12-08T23:35:51Z

crates/bevy_physics/src/d3/ray.rs

+        camera_transform: &GlobalTransform,
+    ) -> Self {
+        if window.id() != camera.window {
+            panic!("Generating Ray from Camera with wrong Window");


Correct me if i'm wrong, this can terminate the program?

It can, you're right. This is by design. Passing a non-matching window and camera to from_mouse_position(..) would result in undefined behavior and should be checked before calling the method. Do you think a Log Error would be more sensible? I didn't familiarize myself very much with the Diagnostics Plugin, so maybe that could help.

TBH I don't know the right answer, I am learning here 👍

MarekLg · 2020-12-09T10:44:29Z

crates/bevy_physics/src/d3/intersectors.rs

 impl RayIntersector for Triangle {
    // using the Moeller-Trumbore intersection algorithm
+    // Can anyone think of sensible names for theese?
+    #[allow(clippy::many_single_char_names)]


Is this allow acceptable?

MarekLg · 2020-12-09T10:44:37Z

examples/physics/raycast.rs

 }

+// Is there a way to reduce the arguments?
+#[allow(clippy::too_many_arguments)]


Is this allow acceptable?

alice-i-cecile · 2021-01-24T18:00:42Z

We have a community crate for this now as well: bevy_mod_raycast. It has significantly more functionality, and I've recently done a full code review on it for quality.

I definitely think this functionality is useful though, and I'm of the opinion that raycasting probably deserves a home in bevy itself once it matures a bit more and we want to build functionality (like the editor, PBR or convenience functions) on top of raycasting.

smokku · 2021-01-24T19:24:07Z

I'm not sure merging everything under Bevy umbrella is a sustainable approach. This creates a contract for supporting these things.

Maybe it would be better to provide an easy way of adding&integrating 3rd party plugins - like a "plugin store" etc.

cart · 2021-01-25T02:17:25Z

Yeah I've been holding off on this because first party raycasting isn't a priority and its a relatively opinionated feature. In the short term, do I think it makes sense to let the community handle raycasting in 3rd party plugins.

Eventually I think we'll need to adopt something officially, at least for the editor. But I think that raycasting is a common enough operation that we will want an official general-purpose solution (in the long term).

I also agree that a "plugin store" is a good idea. Crates.io isn't great for Bevy plugin discovery and awesome-bevy isn't great at sorting / prioritizing / finding information.

I think eventually we should migrate awesome-bevy to a more interactive / informative alternative on bevyengine.org. It would basically be a database of crates.io links with additional metadata (images, category, etc) and a searchable interface. I can't say I will prioritize that in the short term though :)

bonsairobo · 2021-03-24T02:56:49Z

@cart Looking back on this, I still want to push for having 1st party support for at least the bare-minimum functionality that calculates a ray (position, vector) from screen coordinates and a camera (transform, projection). This math is not trivial and can vary based on how the engine implements cameras.

I agree that doing much more than that is probably not a high priority.

alice-i-cecile · 2021-03-24T04:06:18Z

@bonsairobo I agree with the need for first-party support. I expect that @aevyrie will be working on a raycasting RFC, following up on the geometric primitives chain of work.

aevyrie · 2021-03-24T04:47:10Z

Thanks for the ping. 😄

In short, I agree with:

I'm not sure merging everything under Bevy umbrella is a sustainable approach. This creates a contract for supporting these things.

If you have suggestions for API/features in bevy_mod_raycast, I'm always happy to work with contributions, or you could fork it and start up an alternative crate to try out something different!

Until the feature becomes a priority for the engine, we can continue to experiment in external crates without burdening the engine with more code to support.

mockersf · 2024-01-10T08:06:43Z

most of this exist now in Bevy except ray intersection with a sphere or a triangle

MarekLg added 3 commits October 2, 2020 12:44

first draft and example

0f02b01

forgot to add those

dd99c79

added triangle intersector

1f31d00

memoryruins added the C-Feature A new feature, making something new possible label Oct 4, 2020

MarekLg mentioned this pull request Oct 6, 2020

Add a "screen ray" method #197

Closed

smokku reviewed Dec 4, 2020

View reviewed changes

MarekLg added 4 commits December 4, 2020 11:31

merged upstream

dcce5e7

merge upstream

be23d74

added from_window(..)

5fb710a

fixed from_window(..)

29f5d50

marko-lazic reviewed Dec 8, 2020

View reviewed changes

MarekLg added 5 commits December 9, 2020 10:32

renamed HitPoint.t to distance

0b93d4b

added meaningful variable names

bfe5690

adjusted RayHit variable names

f771a90

used spaces instead of tabs

22e62f7

changes for clippy

3a0b376

MarekLg commented Dec 9, 2020

View reviewed changes

changes for clippy

7bed280

Base automatically changed from master to main February 19, 2021 20:44

alice-i-cecile mentioned this pull request Apr 2, 2021

Add a function for computing a world point from a screen point #1799

Closed

alice-i-cecile added the S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged label Apr 23, 2021

cart added the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Jul 23, 2021

DJMcNab removed the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Aug 7, 2021

alice-i-cecile added X-Needs-SME This type of work requires an SME to approve it. A-Math Fundamental domain-agnostic mathematical operations labels Apr 22, 2022

mockersf closed this Jan 10, 2024

alice-i-cecile mentioned this pull request Mar 7, 2024

Upstream and use bevy_mod_picking #12365

Closed

16 tasks

Uh oh!

Conversation

MarekLg commented Oct 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bonsairobo commented Dec 4, 2020

Uh oh!

smokku commented Dec 4, 2020

Uh oh!

bonsairobo commented Dec 4, 2020

Uh oh!

bonsairobo commented Dec 4, 2020

Uh oh!

smokku commented Dec 4, 2020

Uh oh!

smokku Dec 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alice-i-cecile commented Jan 24, 2021

Uh oh!

smokku commented Jan 24, 2021

Uh oh!

cart commented Jan 25, 2021

Uh oh!

bonsairobo commented Mar 24, 2021

Uh oh!

alice-i-cecile commented Mar 24, 2021

Uh oh!

aevyrie commented Mar 24, 2021

Uh oh!

mockersf commented Jan 10, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

MarekLg commented Oct 2, 2020 •

edited

Loading

smokku Dec 4, 2020 •

edited

Loading