Hello guys.
Just curious to know how these functions compute intersecting position?
Any explanation would be appreciated.

Hi,

do you mean “how do they do it mathematically” or do you mean “how do they do it so that the user can benefit from it”?

As for the later … my “environment aware animation rig” tutorial shows how to use the function at around minute 10:38 (according to the directory at the beginning of the video )
https://vimeo.com/211124606 [vimeo.com]

Marc

I guess Nima rather wants to know how it's computed. But if someone's interested in how to use the function first, here goes:

Hi,

yeah, that's the short form :-) The only point I'd like to add is that you should check “prim” for being greater or equal zero. Because it can be “-1” if there is no intersection found either in the direction given or within the range (length of the direction vector). By ignoring that your “@P” can get false values.

Marc

Hello guys.
Thank you for your answers.
I know how to use them but I don't now how do they do it mathematically.
These functions use a lot when rigid bodies collision happening (when surface collision is enable).
Thank you guys for your help.

Hi Marc,

you're correct. I added an if statement to my example code and file.

Nima
I know how to use them but I don't now how do they do it mathematically.

I guess if you research raytracing, building acceleration structures, ray/plane, ray/poly, ray/… intersections you will get the idea how they work matematically, or at least what algorithms are out there to write similar functions from scratch

Hi,

I don't know how Houdini is doing it specifically, but in general I'd say the approach is:
- check if the ray is parallel to the plane of each polygon you need to check (this you can get from a octtree for all points within the sphere described by the ray length)
- if yes, bail out: No intersection
- if no, we might have an intersection, now gow through all “edges” on each polygon in question and check if a potential point on the ray lies on the same side (“inside the polygon”) of the ede
- if no, bail out for this polygon and continue with next, no intersect found so far
- if yes, we got a hit: Now all you do is get the weight for the points describing the hit-polygon and write those to “UV” coordinates

@Konstantin: If I am allowed to nitpick again … I'd also add a fail-condition to write some “meaningful” values to “@P” if no intersection is found (i.e. for “prim=-1”) …

Marc

tamte

Nima
I know how to use them but I don't now how do they do it mathematically.

I guess if you research raytracing, building acceleration structures, ray/plane, ray/poly, ray/… intersections you will get the idea how they work matematically, or at least what algorithms are out there to write similar functions from scratch

Thanks Tomas.
Have you any good reference for raytracing?
In wikipedia, I saw a C++ code for pathtracing but not for raytracing.
This was (Algorithm section):
https://en.wikipedia.org/wiki/Path_tracing [en.wikipedia.org]
———————————————————–
@Mark:
The challenge is how to do this line:
if no, we might have an intersection, now gow through all “edges” on each polygon in question and check if a potential point on the ray lies on the same side (“inside the polygon”) of the ede
The main problems are two things:
1-Time complexity.
2-Massive data when these functions need to be done on a dense model.

malbrecht
If I am allowed to nitpick again

yes, sure!

malbrecht
I'd also add a fail-condition to write some “meaningful” values to “@P” if no intersection is found

but why?
if it's -1, the points just stay where they are!

> but why?
> if it's -1, the points just stay where they are!

… if that is “meaningful”: Absolutely fine!

My thought was that if the code snippet is to demonstrate the overall function, that case (which is a valid one) should be handled, even if it was just with “@P=@P” - or, even more minimalistic, a comment.

I did mention I was going to “nit pick”, right?

Marc

malbrecht
My thought was that if the code snippet is to demonstrate the overall function, that case (which is a valid one) should be handled, even if it was just with “@P=@P” - or, even more minimalistic, a comment.

I did mention I was going to “nit pick”, right?

No, no, you are totally right. For educational purposes there should be an else statement, as well.

@nima: sorry for having gone off-topic.

maybe search for ray casting as that may be more of what intersect does, but ray tracing and path tracing are all using it so never hurts to broaden your horizons, I'm not really into C++ so I don't really know which resources are the best, but there is a plenty of ray/pathtracing books that will have to describe ray casting at some point so I guess any of them will work

Thanks Tomas.
Seems ray casting is a better keyword for searching.

To confirm what was guessed above, if intersect is called, VEX builds and caches an acceleration structure for the geometry that's being intersected, which can take quite a bit of time, but makes additional calls faster. For example, if the geometry being intersected has a lot of primitives in it, calling intersect 100,000 times (e.g. once for each of 100,000 points being run over) might not be much more expensive than calling it once, because of the time spent building the acceleration structure. It's been a while since I profiled the performance, though, so I don't have specific timing data for ya.

Hi, just stumbled upon this, as I’m doing some ray casting of my own… how is the acceleration structure cached? Suppose I’m running the vex code in a wrangle, would there be a pragmatic benefit in building an acceleration structure myself?

Cheers,
Rafael