[Closed] Standard Right and Left click with MouseTrack

In case you’re out of luck – you can always write your own mouse tool type thing. It’s likely to be slower on large scenes, but here you go just in case…

 rollout test "test" width:100 height:100 (
 	timer ticktock interval:100
 	on ticktock tick do (
 		local screenRay = mapScreenToWorldRay mouse.pos
 		if (intersectRayScene != undefined) then ( -- 3ds Max 2008
 			local rayHits = intersectRayScene screenRay
 			for hit in rayHits do (
 				local hitPoint = interSectRayEx hit[1] screenRay
 				format "% -> %
" hit[1].name hitPoint
 			)
 		)
 		else ( -- older max versions
 			for o in geometry do (
 				local hit = interSectRayEx o screenRay
 				if (hit != undefined) then (
 					format "% -> %
" o.name hit
 				)
 			)
 		)
 	)
 )
 createDialog test 
 

Quick description and notes…
This basically creates a rollout with a timer which you’ll need to get ‘continuous’ feedback. 100ms interval should be plenty but increase/decrease if needed, obviously.
When it ticks, it gets the mouse’s position in the viewport and constructs a ray from that.
This ray is then hit tested against the scene.

• For max2008 there’s a handy little function intersectRayScene that tests against all of the scene for you, but has as down side that it only returns the hitpoint and normal, not the face index and barycentric coordinates as well. So another test is run on valid hits to get that information. If you don’t need that, you can kill that part of the code.
• For older versions there’s a simple loop over all geometry in the scene. You could limit this to a given set of objects which might even make it faster than intersectRayScene, but I haven’t tested this. This calls IntersectRayEx to get at the face number and barycentric coordinates; if you don’t need those, use standard IntersectRay instead.
  The hit result is then formatted to the listener.

Notes:

• This will keep returning results even if you do nothing with your mouse, so you may wish to check that mouse.pos (or sliderTime, in case of testing against animated playback) actually changes before invoking the rest of the code.
• Remove the if test for intersectRayScene from the loop by checking if it’s available or not and setting up a function based on that, to speed things up a slight bit.
• Move the dialog for the timer off-screen if you don’t want to see it, or use .NET to create an invisible time interval instead. If you already have a UI to go with your script, the timer UI element should do just fine.
• Check against keyboard.altPressed|controlPressed|shiftPressed if you need that information (supplied as standard in a mouseTool).

The up side of this approach is that all of the standard viewport interactions should remain in effect – selecting, quad menus, etc. The down side is that it’s probably slower than the built-in mouseTool. This ran plenty fluid on my P1.6M for an archviz scene from one of our clients, however – but YMMV.