I can’t get the intersectRay method to work double sided.
this works:
theIntersect = intersectRay msh theRay
but this does not:
theIntersect = intersectRay msh theRay doubleSided:true
The error I am getting is:
-- Argument count error: intersectRay wanted 2, got 5
I thought I read in the reference that intersectRay would take doubleSided as an argument. Was I mistaken? If so, is there some other way to get intersectRay to work on surfaces facing away from it?
For the context in which I am trying to make this work, check the script I posted here: http://forums.cgsociety.org/showpost.php?p=5378757&postcount=5
It never has. I found it funny quoting the MAXScript Reference from top of your head. Even I first go and check what it says. There is no word on a doubleSided: parameter in the IntersectRay() or IntersectRayEx() documentation. I checked.
There IS a doubleSided: option in the RayMeshGridIntersect methods. That’s probably what you remembered.
That being said, intersectRay() will do double-sided intersections with parametric spheres. This is a special case because it does not use the mesh of a Sphere/Geosphere primitive but the mathematical surface and thus returns intersections from both sides.
Having a doubleSided: option in those methods would be useful. Might be a good Wish List item.
You’re right, it was the RayMeshGridIntersect method. And I was looking at it, I just misunderstood what I was reading. Been staring at the screen too long…
I think I have a solution, however. Well, it won’t check double sided, but it will check for rays facing the opposite direction: just flip the normals on the mesh in question, check the intersections, and then flip the normals back. Well, it seems like it will work, I’ll try it out in a bit and post my results.
Meanwhile, if anyone has a more elegant solution, I’m all ears :hmm:
This doesn’t fall under “more elegant” but it would be another way.
Calculate a point along your ray on the opposite side of the bounds of your mesh and shoot back the other direction.
I forget what sort of results intersectraymesh gives you. If there are multiple intersections you would need to account and sort for that with some sort of distance sort.
I don’t know if that would be faster than just inverting the normals though. I could easily see it being significantly slower.
Actually, I did find a more elegant solution, at least for my particular case. The script is posted at http://forums.cgsociety.org/showthread.php?f=98&t=670292
Wait, no, my elegant solution didn’t work. I have to say I was mortified when I realized that I had been doing all my testing with spheres, when Bobo already said that they interact differently than other objects with IntersectRay.
Fortunately, I recovered my wits, and decided to try flipping the normals. My theory worked, and it was actually substantially easier to implement than I had imagined it would be. (Now posted in the same thread already mentioned.)