I have not found any efficient ways to reliably return good results performing this very basic task in Maxscript.
Am I missing something here, or do we still not have access to one of the most fundamental functions imaginable in scripting?
there are two types of ‘hit test’
hit to select
hit to mesh intersect
what do you really want?
There was at last count at least two hit-testing API’s in maxscript that can do that. Plus the mousetrack functions mentioned above.
Mousetrack doesn’t play well with epoly. I can’t comment on the two others as you don’t mention them by name.
These are old, and despite my logging a few bugs against them years ago (As an internal employee) no one was interested in fixing them:
So as I remember, years ago, I had limited success with them. So go ahead and give them a try.
Was’nt there some new method implemented and exposed in Max 2015 for the new placement tool? Maybe i should’ nt mention it because it’s not released yet…
Thanks, AlpineMan. I have been staying away from anything with an acceleration structure, for performance concerns. The script is triggered by external input and may be called up to 10 times/second, with no guarantee that the meshes haven’t changed between each time.
The scary aspect of IntersectRay, IntersectRayScene is that they will work as advertised in most cases, but occasionally will give bogus results. I’m noticing those bad results a lot now since the functions are called so frequently.
Has to be backwards compatible though
Any hit testing will require iterating through the scene graph, updating all dependencies in the INode’s and their meshes. So it will always be expensive anyway you look at it. Even just hovering your mouse around in the viewport will do what I just described, just so you can get a silly little popup window with the name of the object…
Well, I was playing with an idea of using a scene change event to update everything, though at that point it’s starting to get ugly…
Miauu, I came across that, but couldn’t find that anyone had actually used it. Have you had success with it?
Hi DenisT, ultimately mesh intersect, to get the face under the cursor of any object in the scene in real-time as the user moves the mouse pointer. In the past I’ve been using a plugin that exposes PolyObject::IntersectRay to Maxscript (resulting in an epoly version of IntersectRayEx). It’s only now that I’m calling it a lot that I find it quite frequently gives wrong, and seemingly random, results.
I use it in one of my scripts to select splines under the cursor and it works pretty well. For mesh objects I use IntersectRay which works with editable poly objects with no problems.
Try this:
(
objsUnderCursorArr = (boxPickNode (box2 (mouse.pos - [2,2]) (mouse.pos + [2,2])) crossing:true )
)
The result will be an array with all objects under the cursor.
that’s exactly the ways i usually use. the only difference is i prefer RayMeshGridIntersect
I’m having issues with seemingly any kind of ray hit under max 2009. I’ve tested 2014 without issues, and do not know about any versions in between the two.
Example code:
(
fn G3P_getObjUnderCursorE =
(
local oList = #()
for o in Geometry do
if (intersectRay o (mapScreenToWorldRay mouse.pos)) != undefined then
append oList o.name
format "%
" oList
)
G3P_getObjUnderCursorE()
)
Test scene below(something like a production mesh, as I never ran into this issue with standard “programmer’s test scenes of boxes and teapots”)
www.per128.com/pub/crap/per128_JigSawTest.max
Results:
As I keep evaluating the above code while moving the mouse pointer over the scene (even holding down CTRL+E to trigger it repeatedly), much of the time I’ll get good results. Sometimes it seems impossible to get bad results. Then I rotate the viewport slightly, or make a selection change, or interact with the app in some way, and suddenly it seems impossible to get a good result. It will return hits on objects which are nowhere near the mouse pointer.
I’ve used ray hit methods for years in 2009 without much of a problem, but these were scripts where the function was triggered so rarely that on the occasions it didn’t work, the user would just rotate the view and try again and not think much of it. When the script relies on continuously getting accurate results several times a second, these issues become much more significant.
I’m trying to see whether this can be fixed in the SDK, by comparing 2009 and 2014 SDKs, but I have very limited experience with the SDK, so I might be looking at a solution without realizing it.