2
$\begingroup$

I have a cylinder that has a vertex group named Light_Spawn where 4 vertices have a value of $1.0$.

I spawn those cylinders on a plane, and when they are spawned, I want to perform raycasts from those 4 vertices. If they hit, then they should instance an object on that position.

So in this images, the boxes with a red cross should not be there cause the raycast should have missed.

enter image description here

enter image description here

For some reason it's always a hit. If I alter the Source Position then some disappear, but I also get a missing one where there should be one.

What am I doing wrong?

enter image description here

enter image description here

$\endgroup$

1 Answer 1

5
$\begingroup$

First problem you figured out is that you run into a common issue with Raycasting: You're raycasting from a point, onto a geometry that contains this point. So if you don't offset the starting position, your Hit Distance will be $0$, because you will hit yourself immediately. And the way you solved your problem is the proper, standard way to do it.

Second problem is that your ray directions aren't what you expect them to be. Try replacing your instances with cylinders or some arrows and use "Align Euler to Vector" to debug and see what's happening:

If you make the cylinder long enough and let it go in both ways by removing the "Transform Geometry" node, you will see those directions are all crossing the origin:

And if you preview the geometry used, you will see you operate on naked verts, no faces:

A normal of a face is a ray perpendicular to the surface of the face. But what is a normal of a vertex? It's an interpolation of normals of faces built on that vertex. But what if there is no face? Then it's simply a normalized position of the vertex:

(Normalize node above is insignificant, because Align Euler to Vector doesn't care about a magnitude=length of a vector)

So you need to capture the normal when it still represents something meaningful - before separating vertices from their faces, and use that:

And therefore your setup becomes:

$\endgroup$
4
  • $\begingroup$ Thanks for the in great detail reply. I try to replicate your steps for the purpose of learning. But when I try the "Align Euler to Vector" step I get not what you have, neither when playing with the parameters. Mind having a look? blend-exchange.com/b/W4a2mAo2 $\endgroup$
    – clankill3r
    Commented Jul 31, 2023 at 6:20
  • $\begingroup$ @clankill3r that's a common mistake too :) You use the input "Rotation" of the "Align Euler to Vector", but this input is meant to rotate the vector before aligning it. Meanhwile the vector you're aligning to is supposed to be plugged to "Vector" input. Also you could think of Vectors and Rotations as different types, that in current versions of Blender share the same interface ("dark slate blue" color socket), as they both use an array of 3 float values. Maybe in future the sockets will differ just like the color type has a separate yellow color… And "Normal" is a vector, not a rotation. $\endgroup$ Commented Jul 31, 2023 at 8:08
  • $\begingroup$ In fact you could think of "Align Euler to Vector" as converting from vector type to rotation type, as (basically) it's the same information, just expressed in a different way. BTW, maybe color sockets have a different socket color (yellow instead of blue), because they sometimes contain a 4th value alpha, though that changes from version to version… $\endgroup$ Commented Jul 31, 2023 at 8:09
  • $\begingroup$ A damn, I didn't see that, thanks for pointing that out. $\endgroup$
    – clankill3r
    Commented Jul 31, 2023 at 10:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .