Page MenuHome

Geometry Node: Raycast correct field dependencies
ClosedPublic

Authored by Iliya Katueshenock (Moder) on Oct 23 2022, 10:20 PM.

Details

Summary

Outgoing sockets are depends for the evaluation call data: position, direction vector, and length.
An attribute of an random type belongs to the geometry and is evaluated in the node.
Therefore, all output attributes depend on the evaluation call data and not on the sampling geometry data.
This patch exposes the dependencies of all output 3 call data input attributes.


Examples:

BeforeAfter

Diff Detail

Event Timeline

Iliya Katueshenock (Moder) requested review of this revision.Oct 23 2022, 10:20 PM
Iliya Katueshenock (Moder) created this revision.
Iliya Katueshenock (Moder) edited the summary of this revision. (Show Details)
Iliya Katueshenock (Moder) retitled this revision from Geometry Node: Ray Cast correnct fields depends to Geometry Node: Ray Cast correnct field depends.Oct 23 2022, 10:25 PM
Iliya Katueshenock (Moder) edited the summary of this revision. (Show Details)
Iliya Katueshenock (Moder) retitled this revision from Geometry Node: Ray Cast correnct field depends to Geometry Node: Raycast correct field dependencies.Oct 23 2022, 10:28 PM
Iliya Katueshenock (Moder) edited the summary of this revision. (Show Details)
Hans Goudey (HooglyBoogly) requested changes to this revision.Nov 6 2022, 10:40 AM

Thanks for the patch. I'm not sure this is totally right for the "Attribute" output socket. Even if the source position, ray direction, and ray length sockets are all single values, if the attribute input is a field, they will be dependent on that field.
For the first four outputs, I think the fix is valid, I think the correct solution is just adding the two missing dependencies for the "Attribute" output sockets.

This revision now requires changes to proceed.Nov 6 2022, 10:40 AM

Why is sampling something with a single keys, the output must be designated as a field (even though the logging value is single)?

Edit: The problem is that if we are sampling values from the surface of the cube, then whether it is a field or not should not matter. The number of results (single or other domain) does not depend on this.

Edit 2:

auto fn = std::make_unique<RaycastFunction>(std::move(target), std::move(field), mapping);
auto op = std::make_shared<FieldOperation>(FieldOperation(
    std::move(fn),
    {std::move(position_field), std::move(direction_field), std::move(length_field)}));

This line of code should mean exactly that the fact that the output field depends only on the fact that it is created based on position, vector and length.

I see your point. You're probably right but I'm not totally sure. Single values can still be fields that we depend on.

Single values can still be fields that we depend on.

Not sure what you meant

If imagine a little:
You can sample some value. In this case, from the surface of the cube. This value can be either a single value for all points or a field.

Sampling, like querying a value from a cube, is an operation, the amount of which depends on how many keys to sample. That is, there are as many results as there are keys (position, length, vetcore).

If the sample is from a surface with a single value, this simply means that all requests for a value receive the same thing.

Looks correct to me.
The attribute input is evaluated in the node directly, the output field does not depend on that anymore.

This revision is now accepted and ready to land.Nov 13 2022, 3:32 AM