Geometry Nodes: Ray Cast Node #88078

New Issue

Jacques Lucke · 2021-05-06T14:58:46+02:00

Jacques Lucke commented

2021-05-06 14:58:46 +02:00

We decided to have a separate Ray Cast node and not to have it as a mode in the Attribute Transfer node. The main reason is that the functionality is conceptionally quite different on the user level and that it needs a different set of inputs.

Inputs:

Geometry
Source Geometry
Ray Direction (vector or attribute)
Max Ray Length?
Hit Position result attribute (vector)
Hit result attribute (boolean)
Attribute to transfer (can be a string list in the future, for now just one attribute)

Outputs:

Geometry

The exact name of the input sockets still has to be determined.

We decided to have a separate Ray Cast node and not to have it as a mode in the Attribute Transfer node. The main reason is that the functionality is conceptionally quite different on the user level and that it needs a different set of inputs. Inputs: * Geometry * Source Geometry * Ray Direction (vector or attribute) * Max Ray Length? * Hit Position result attribute (vector) * Hit result attribute (boolean) * Attribute to transfer (can be a string list in the future, for now just one attribute) Outputs: * Geometry The exact name of the input sockets still has to be determined.

Jacques Lucke commented

2021-05-06 14:58:46 +02:00

Added subscriber: @JacquesLucke

Miro Horváth commented

2021-05-06 15:47:49 +02:00

Added subscriber: @MiroHorvath

Miro Horváth commented

2021-05-06 15:47:49 +02:00

@JacquesLucke is the Max Ray Length something(when set wisely) what can lead to a better performance of the node?

Jacques Lucke commented

2021-05-06 15:53:52 +02:00

Yes, also it could help to avoid artifacts when you don't want to ray cast onto some geometry that is far away accidentally.

Gregory commented

2021-05-06 18:14:00 +02:00

Added subscriber: @GregoryS

Zijun Zhou commented

2021-05-06 22:51:12 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2021-05-06 22:51:12 +02:00

What does this ray cast node do? The only ray cast feature I know is like the DoF Picker in camera view, which just detects the distance between the camera and the object (and IMHO this really needs a more obvious UI buttom). Is this node doing something similar? Detect distance between objects or something? I am not quite sure

Kenzie commented

2021-05-07 00:21:15 +02:00

Added subscriber: @KenzieMac130

Bent Hillerkus commented

2021-06-09 15:42:48 +02:00

Added subscriber: @bent

Bent Hillerkus commented

2021-06-09 15:42:48 +02:00

In #88078#1157095, @Eary wrote:
What does this ray cast node do? The only ray cast feature I know is like the DoF Picker in camera view, which just detects the distance between the camera and the object (and IMHO this really needs a more obvious UI buttom). Is this node doing something similar? Detect distance between objects or something? I am not quite sure

I believe it should shoot for every point in the input geometry a ray into the source geometry and copy the attribute value on the source geometry at the hit position onto the point from which the ray was shot

> In #88078#1157095, @Eary wrote: > What does this ray cast node do? The only ray cast feature I know is like the DoF Picker in camera view, which just detects the distance between the camera and the object (and IMHO this really needs a more obvious UI buttom). Is this node doing something similar? Detect distance between objects or something? I am not quite sure I believe it should shoot for every point in the input geometry a ray into the source geometry and copy the attribute value on the source geometry at the hit position onto the point from which the ray was shot

Lukas Tönne commented

2021-06-12 11:49:37 +02:00

Added subscriber: @LukasTonne

Lukas Tönne self-assigned this 2021-06-12 11:49:37 +02:00

Lukas Tönne commented

2021-06-12 11:49:37 +02:00

I've started working on this.

One question about naming: I assume the "Geometry"/"Source Geometry" names are based on the attribute transfer node? For raycasting i would call these something like "Geometry" (where the rays come from) and "Cast Geometry" (that the rays are projected onto). "Source" would be confusing IMO since the rays are cast onto it, even though technically it is still the source of returned values like hit points, normals, interpolated values. Any other naming preferred?

I've started working on this. One question about naming: I assume the "Geometry"/"Source Geometry" names are based on the attribute transfer node? For raycasting i would call these something like "Geometry" (where the rays come from) and "Cast Geometry" (that the rays are projected onto). "Source" would be confusing IMO since the rays are cast onto it, even though technically it is still the source of returned values like hit points, normals, interpolated values. Any other naming preferred?

Miro Horváth commented

2021-06-16 13:23:23 +02:00

Hi @LukasTonne, while testing up Raycast node branch I realized that a handy option could make into the final node. Similar functionality already exists in Shrinkwrap modifier(Project method == raycast) which allows user to raycast in both directions(Positive/Negative see screenshot).

In the scenario below I'd like to project(cast) points generated on a plane onto the terrain. For the points to the right from red line(above terrain) I'd use Raycast node with ray direction set to (0,0,-1) and then use hit distance to offset/snap them to the terrain. Currently for the points to the left(below terrain), I need to first filter them based on Hit attribute with Point Separate node(all False ones), then plug another Raycast node now with ray direction set to (0,0,1) and do the rest again. I tested this workflow in the current branch and it works fine, but I think that such scenario can be done easily with just one Raycast node.

It'd be much more handy to have boolean option eg. "Negative as well" which when set to True would do raycast in both direction, in the first loop along the vector set in Ray direction, then second loop(not hit in the first loop) in the opposite direction. Then Hit distance attribute would return positive distances for points hit in the first loop and negative distances from the second loop. What do you think?

Hi @LukasTonne, while testing up Raycast node branch I realized that a handy option could make into the final node. Similar functionality already exists in Shrinkwrap modifier(Project method == raycast) which allows user to raycast in both directions(Positive/Negative see screenshot). In the scenario below I'd like to project(cast) points generated on a plane onto the terrain. For the points to the right from red line(above terrain) I'd use Raycast node with ray direction set to (0,0,-1) and then use hit distance to offset/snap them to the terrain. Currently for the points to the left(below terrain), I need to first filter them based on Hit attribute with Point Separate node(all False ones), then plug another Raycast node now with ray direction set to (0,0,1) and do the rest again. I tested this workflow in the current branch and it works fine, but I think that such scenario can be done easily with just one Raycast node. It'd be much more handy to have boolean option eg. "Negative as well" which when set to True would do raycast in both direction, in the first loop along the vector set in Ray direction, then second loop(not hit in the first loop) in the opposite direction. Then Hit distance attribute would return positive distances for points hit in the first loop and negative distances from the second loop. What do you think? ![image.png](https://archive.blender.org/developer/F10174846/image.png)

Lukas Tönne commented

2021-06-16 14:00:02 +02:00

In #88078#1177624, @MiroHorvath wrote:
Hi @LukasTonne, while testing up Raycast node branch I realized that a handy option could make into the final node. Similar functionality already exists in Shrinkwrap modifier(Project method == raycast) which allows user to raycast in both directions(Positive/Negative see screenshot).

In the scenario below I'd like to project(cast) points generated on a plane onto the terrain. For the points to the right from red line(above terrain) I'd use Raycast node with ray direction set to (0,0,-1) and then use hit distance to offset/snap them to the terrain. Currently for the points to the left(below terrain), I need to first filter them based on Hit attribute with Point Separate node(all False ones), then plug another Raycast node now with ray direction set to (0,0,1) and do the rest again. I tested this workflow in the current branch and it works fine, but I think that such scenario can be done easily with just one Raycast node.

It'd be much more handy to have boolean option eg. "Negative as well" which when set to True would do raycast in both direction, in the first loop along the vector set in Ray direction, then second loop(not hit in the first loop) in the opposite direction. Then Hit distance attribute would return positive distances for points hit in the first loop and negative distances from the second loop. What do you think?

This sounds like feature creep to me. It's a pretty specific scenario and i want to keep the number of options as low as possible. The raycast node is already quite big. A feature like this could just as well be done with a node group and have more flexibility too, with no additional perf cost because it would do two independent raycasts anyway.

> In #88078#1177624, @MiroHorvath wrote: > Hi @LukasTonne, while testing up Raycast node branch I realized that a handy option could make into the final node. Similar functionality already exists in Shrinkwrap modifier(Project method == raycast) which allows user to raycast in both directions(Positive/Negative see screenshot). > > In the scenario below I'd like to project(cast) points generated on a plane onto the terrain. For the points to the right from red line(above terrain) I'd use Raycast node with ray direction set to (0,0,-1) and then use hit distance to offset/snap them to the terrain. Currently for the points to the left(below terrain), I need to first filter them based on Hit attribute with Point Separate node(all False ones), then plug another Raycast node now with ray direction set to (0,0,1) and do the rest again. I tested this workflow in the current branch and it works fine, but I think that such scenario can be done easily with just one Raycast node. > > It'd be much more handy to have boolean option eg. "Negative as well" which when set to True would do raycast in both direction, in the first loop along the vector set in Ray direction, then second loop(not hit in the first loop) in the opposite direction. Then Hit distance attribute would return positive distances for points hit in the first loop and negative distances from the second loop. What do you think? > ![image.png](https://archive.blender.org/developer/F10174846/image.png) This sounds like feature creep to me. It's a pretty specific scenario and i want to keep the number of options as low as possible. The raycast node is already quite big. A feature like this could just as well be done with a node group and have more flexibility too, with no additional perf cost because it would do two independent raycasts anyway.

Dalai Felinto commented

2021-06-21 14:58:09 +02:00

Changed status from 'Needs Triage' to: 'Resolved'

Dalai Felinto closed this issue

2021-06-21 14:58:09 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry Nodes: Ray Cast Node #88078