IntersectRayScene completely broken with editable poly!?

[senorpablo]

I've spent hours trying to get IntersectRayScene to work properly. Can someone verify if this is broken or if I'm just losing my mind? 

According to the documentation for IntersectRay (IntersectRayScene doesn't go into detail), back faces are ignored:

"Returns undefined if the ray does not intersect the node, the faces it does intersect point away from the ray's position, or the node does not have a surface."

http://help.autodesk.com/view/3DSMAX/2018/ENU/?guid=__files_GUID_D1D7EB56_A370_4B07_99B4_BC779FB87CA...

If I use the included example: 

(
local r = ray [0,0,0] [1,0,0]--define a ray along X
for i = 0 to 4 do--loop 5 times
(
 box pos:[i * 30, 0,0]--create a box
)
local hits = intersectRayScene r--intersect withscene
print hits --Misses box 1 because ray originates inside the box
)

I get 4 hits when I run this as-is, and it does appear to ignore back faces as the comment on the last line of code suggests. However, if I convert these boxes to editable poly and comment out the box creation line, and run again, I get 5 hits! As if back faces are not ignored for editable poly objects. Naturally this is a problem because editable poly objects are extremely common. Editable Mesh objects seem to work properly. 

But wait, there's more! So long as the boxes remain primitives, the ray appears to work as a ray. That is, it starts at a point and goes in one direction only. But! If there are editable poly objects in the scene, the ray no longer behaves as a one directional ray, and instead appears to cast in both directions!

To test, run the example again to generate box primitives, then move the 4 boxes in +x to -x. Run again and you get 0 hits. All the faces are back facing, or in the other direction of the cast ray. Convert any of those 4 boxes to editable poly, and now you'll get hits, even though the ray is being cast in the opposite direction(+x).

I have this issue in both Max 2018.3 and 2020.1.

[denisT.MaxDoctor]

you just do something wrong.. try the snippet. It works right and how it's expected:

(
	delete objects 
	
	local r = ray [0,0,0] x_axis
	for i = 0 to 4 do
	(
		b = box pos:[i * 30, 0, 0]
--		converttomesh b
--		converttopoly b
	)
	hits = intersectRayScene r
	format "hits count:%\n" hits.count 
)

[senorpablo]

---

@denisT.MaxDoctor wrote:

you just do something wrong.. try the snippet. It works right and how it's expected:

(
	delete objects 
	
	local r = ray [0,0,0] x_axis
	for i = 0 to 4 do
	(
		b = box pos:[i * 30, 0, 0]
--		converttomesh b
--		converttopoly b
	)
	hits = intersectRayScene r
	format "hits count:%\n" hits.count 
)

---

Hi Denis,

Thanks for looking into this. 

I get 5 hits when converttopoly is enabled, and only 4 with box primitives or editable mesh. 

Also, if you set the ray to -x_axis with primitives, you get 0 hits, and 5 with editpoly. The ray is in the opposite direction!

I'm seeing this behavior on three versions of Max across two completely different installs/computers and versions of Windows. 

Continued in the next post.

[senorpablo]

Try this:

(
	delete objects 
	local r = ray [0,0,0] x_axis
	for i = 0 to 4 do	(
		b = box pos:[i * 30, 0, 0]
		--converttomesh b
		--converttopoly b
	)
	hits = intersectRayScene r
	format "RUN 1 [box prim +x axis] hits count:%\n" hits.count 
)

(
	delete objects 
	local r = ray [0,0,0] x_axis
	for i = 0 to 4 do	(
		b = box pos:[i * 30, 0, 0]
		converttomesh b
		--converttopoly b
	)
	hits = intersectRayScene r
	format "RUN 2 [editmesh +x axis] hits count:%\n" hits.count 
)

(
	delete objects 
	local r = ray [0,0,0] x_axis
	for i = 0 to 4 do	(
		b = box pos:[i * 30, 0, 0]
		--converttomesh b
		converttopoly b
	)
	hits = intersectRayScene r
	format "RUN 3 [editpoly +x axis] hits count:%\n" hits.count 
)


(
	delete objects 
	local r = ray [0,0,0] -x_axis
	for i = 0 to 4 do	(
		b = box pos:[i * 30, 0, 0]
		--converttomesh b
		--converttopoly b
	)
	hits = intersectRayScene r
	format "RUN 4 [box prim -x axis] hits count:%\n" hits.count 
)

(
	delete objects 
	local r = ray [0,0,0] -x_axis
	for i = 0 to 4 do	(
		b = box pos:[i * 30, 0, 0]
		--converttomesh b
		converttopoly b
	)
	hits = intersectRayScene r
	format "RUN 5 [editpoly -x axis] hits count:%\n" hits.count 
)

Output from that code:

RUN 1 [box prim +x axis] hits count:4
OK
RUN 2 [editmesh +x axis] hits count:4
OK
RUN 3 [editpoly +x axis] hits count:5
OK
RUN 4 [box prim -x axis] hits count:0
OK
RUN 5 [editpoly -x axis] hits count:5
OK
OK

[denisT.MaxDoctor]

I can confirm the bug !

MAX 2016 - works right

RUN 1 [box prim +x axis] hits count:4
RUN 2 [editmesh +x axis] hits count:4
RUN 3 [editpoly +x axis] hits count:4
RUN 4 [box prim -x axis] hits count:0
RUN 5 [editpoly -x axis] hits count:0

MAX 2017 - works wrong !!!

RUN 1 [box prim +x axis] hits count:4
RUN 2 [editmesh +x axis] hits count:4
RUN 3 [editpoly +x axis] hits count:5
RUN 4 [box prim -x axis] hits count:0
RUN 5 [editpoly -x axis] hits count:5

Report it to the Autodesk

[senorpablo]

Thanks for confirming. 

Max 2018, 2019, 2020 are all broken as well. 

This is going to make my task substantially more difficult than it needs to be. 

[senorpablo]

As a follow on to this, RayMeshGridIntersect(), and the associated intersectRay function, are also unreliable and buggy. Changing the size of the grid can provide different results, suggesting the "optimization" grid isn't reliable and is incorrectly binning and or missing polygons. 

Autodesk, please give us a working ray intersection method for Maxscript. 

[Anonymous]

I'm glad someone discussed this issue
2021 intersectray same error

[istan]

---

@Anonymous wrote:

I'm glad someone discussed this issue
2021 intersectray same error

---

Yes I confirm, there is a bug with IntersectRay() in Max2017 (and in all service packs), which I reported to them several times. In Max2017 they changed the code to MP and introduced some weird bugs, like for instance wrong face normal consideration. As I now use my own IntersectRay() code in my plugins, I can't say, if they ever fixed..

[Serejah]

---

@istan  написал (-а):

---

@Anonymous wrote:

I'm glad someone discussed this issue
2021 intersectray same error

---

... and introduced some weird bugs, like for instance wrong face normal consideration.

I can't say, if they ever fixed..

---

Looks like they didn't

Had some weird bug using IntersectRay in both 2020 & 2021 a few days ago.

Luckily RayMeshGridIntersect has its own acceleration grid and it worked the way it should.

[Serejah]

Here's the test scene