-3
$\begingroup$

Basically, I want to recreate raycasting without using the raycast node. Why? The way the raycast node works now, is that one geometry casts onto another geometry. And that's all great and fine, until you have the crazy idea to make a single geometry cast onto itself. Then it gets tricky. The raycast node can't help but to hit the geometry at the very start of a ray. And for that reason, you have to use some scaling tricks to avoid that. That much was explained to me here: Can an object raycast onto itself?

Well, scaling the rays just isn't good enough for me. I want more accurate self ray casting. And so I guess if I can figure out the math for raycasting, I can alter whatever variable needs to be altered to avoid hitting at the origin of a ray. But... raycasting math is proving too difficult for me to get on my own. Maybe someone here knows how it's done.

enter image description here

I was thinking something like instancing lines out of points and/or faces of the mesh. Those would act as rays. Then some magic math happens, bibbidi-Bobbidi-Boo, and those lines sample where they intersect faces.

I found a couple of papers explaining how rays are made and how hit detection work. It's just way too advanced for me: https://people.computing.clemson.edu/~dhouse/courses/405/notes/raycast.pdf https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20-%20Raycasting.pdf

This video really breaks it down too: https://www.youtube.com/watch?v=hOeOuZGmeCM

I would appreciate any help with this, as impractical as it may sound.

$\endgroup$
17
  • 1
    $\begingroup$ Could you explain why "Well, scaling the rays just isn't good enough for me" ? $\endgroup$
    – lemon
    Commented Jan 7 at 14:01
  • $\begingroup$ Can't you separate the mesh to "raycast" from one partition to the others ? Is the Ray Direction uniform or local ? $\endgroup$ Commented Jan 7 at 14:39
  • 3
    $\begingroup$ @Smeebit, recreating a raycast in gn (even if it may be possible (?)) will be difficult and most likely inefficient, except if very special cases. Efficient raycast involves particular data structures that cannot be available in gn. That's why it would be better to study how it can be adapted for your case. $\endgroup$
    – lemon
    Commented Jan 7 at 15:39
  • 1
    $\begingroup$ @RobinBetts, yes, this is that blender.stackexchange.com/a/290396/19156... but for some reason that is not what Smeebit expects. $\endgroup$
    – lemon
    Commented Jan 7 at 19:34
  • 2
    $\begingroup$ I guess it's one more time for me to be an a-hole, but if you fail to explain in the question why you need to implement raycasting yourself, you will most definitely fail to implement raycasting yourself :P I'm inclined to downvote based on unclear question, XY problem, as well as the problem "not being fresh" (you could refresh it first before presenting it; though there's nothing wrong with an open discussion like that, just that Stack Exchange is not designed for such discussion, blenderartists.org or discord seem better...) $\endgroup$ Commented Jan 8 at 12:49

2 Answers 2

2
$\begingroup$

@Smeebit

I think offsetting is still the best option.

if you want to get self collisions (which i see from the comments), then offset the (input) position of the raycast by some small amount in the direction of it's velocity [normalize the velocity then scale my small value, then add to position, and this position is source position of raycast].

Through this, it is offset in the directions it is casting and won't hit itself.

If it has no velocity, then calculate as no hit. if you still want to check if it hit itself, then you could input the index into the value input (set it to integer) and compare the output if equal to the index; if it is, then it hit itself (the same vert that cast) so consider it no hit.

I hope this helps.

(btw if you always want the same offset out from the point, then take the sign (not sine) of the dot product between the normal and direction (normalized) and multiply the epsilon (the small value offset) and scale the normal by that and add that to the position (this all as the source position))


If you want to recreate raycast, you'd have to loop through all faces per vertex. This is a complexity of $xn$ (close to $x^2$); $x$ being vertices and $n$ being faces [but really it's more, because per face you have to go through it's vertices etc.). It's possible, but not recommended.

two ways of doing it.

  1. Repeat Zone -

    • set iterations to the vert count
    • and in each iteration have every face sample a single vertexes directory and position and do an intersection
      (you also might have to triangulate the mesh to make the calculation).
    • capture (or store) the hit position of the intersection on that vertex.
      this repeats for all vertices.
    • You'll get multiple answers if it intersects multiple faces. You have to use a dot product or something and compare the one with the least distance that isn't that of the vertex itself.
  2. Same thing but duplicate the mesh $n$ times.

    • for each duplicate use the duplicate index to sample the index with Index.
    • to sample back to the vertex use the vertex index + and accumulate ......🤷‍♂️

Anyway, I highly don't recommend.

$\endgroup$
1
$\begingroup$

(Using Blender 3.6.5)
NB: This is not a full answer; it is to illustrate mesh partitioning.

The approach is to split the geometry in two, and to send rays from on partition toward the other. Setting the Separate Geometry node in Point domain avoids duplicated points, leading otherwise to seemingly self-intersection. An Attribute Statistics node is useful to get the minimal distance, that can be accumulated and compared to a threshold. For complex geometries, both ways (i.e. Selection <-> Inverted) can be tested and more than one partitioning strategy can be combined.

GN graph

Resources:

$\endgroup$

You must log in to answer this question.

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