Dears,
I was for the first time looking into selecting meshes from a ray casted from a first-person camera.
I managed to achieve my goal… but then, I’m a bit confused towards what is the best approach.
In short, I cast a ray with a limited length from a caster(mesh) attached to my camera.
When the ray intersects (or picks) with a pickable object, I want to get the name of this object.
This is where I realized that I was unable to get the name from this method (intersectsMeshes), probably because of my low coding skills? Don’t know.
I found this related to my question topic but it doesn’t bring any answer as to can you or can’t you get the name of a mesh from this method:
In the end, I went for two alternate solutions both using pickWithRay and pickedMesh.
There’s this one solution that uses a function and creates a new ray with each call
and then, there’s this other solution where I use a combination of intersects and pick and the ray is created only once.
Now, the question is:
Is there any difference in terms of performance between these two options?… and then, is any of these 2 methods the correct approach or else, how should I do it?
I would go for the first approach, because on your second solution you check for intersection twice and it goes through all meshes instead of breaking after first intersection. Additionally it requires the RayHelper which would kill perfomance. Also I optimized your code a bit, here my PG:
If you want to get name on second method you can use:
Thanks a million . I believe this is the way to go.
You know, I thought that this solution (#1) I got from the featured PG in the doc was kind of funny.
Only this morning I realized that, when using the helper, it does indeed create a new ray with each runtime and never dispose of the old one. I don’t know why this method is even featured.
As for my pseudo-solution #2, yes, you are right. It does indeed check on twice. Once with intersect and once with pick. The reason is that at first I wanted to use only intersect. Intersect sends a single callback when you start intersecting with the mesh and a single callback when the intersection ends. I found this ‘in-out’ behavior handy to use but as I said, I wasn’t able to get the name of the mesh so I added the pick method to it.
In the end, I believe I can deal with the callback from the pick method. Not a big deal. So again thanks a lot for the optimized code with included meshes array.
I think this revised version you gave me for ray picking from the camera would deserve to be featured in the doc. @Cedric@carolhmj . What do yours think? This method looks to me like something that could be added here.
As a rule of thumb, I always think the best is to do a small benchmark. How much time and memory does it take to do 10000 raycasts? Also, stopping after the first hit has a different impact Vs shortest hit. And if your scene is a bit complex but some geometry overlap, you mays have ‘wrong’ results. That’s something to take care of as well.
@Takemura@Cedric
I actually would have one more question regarding the slick version I marked as a solution. Question is: With this method, can we use the rayHelper? I didn’t find anything to attach the helper to the camera. Does it have to be a mesh?
Before checking out the marked as a solution above I actually opened what I believe was your first version revision @Takemura. The one keeping with the mesh casting the ray and adding an array for included meshes. There was just a little bug with the return (false) causing only the first mesh from the array to return(true). I quickly changed that and ended up with this:
Would yours say that this version can also be ‘recommendable’ if you want to use the helper?
Though since I don’t want to show the ray in the end, I will still go with the ‘marked as solution’ provided and thanks again for that.
Meanwhile, have a great day
Sorry, I wasn’t clear
It looks like it’s possible to add functionnality and API to attach to a Node. The code is not there, obviously but it doesn’t seem hard to add it. Unless I missed a mesh functionnality.
But then if so, I guess it’s easier to parent a mesh or an abstractMesh to the camera as a ray caster, no?
Would it change anything in terms of performance?
Isn’t RayHelper and its attachToMesh only for debug purposes? If you need one with my method you can do like in my current PG above.
And yes my first version was less optimized than the current, it used an additional mesh with camera parent to set ray position and direction by mesh forward, but directly using camera forwardray would be more comfortable and more optimized, I think? If you want to check again just remove #1 on my PG link to view old version.
Yes, I’m just tackling it a bit. As I said, I will use your slick version that seems totally appropriate.
But think of a title like ‘WatchDogs’ where you cast a visible ray from the character to the target.
I know the rayHelper is mainly a debug feature but it actually uses the lineSystem to draw a line from the origin to the target and this is pretty much what you would do in case you want to show a ray, no?
Edit: Forget the above. There will always be other necessary tweaks and I guess it’s easier and more convenient in this case to create your own. So it makes sense that the helper remains just a debug tool.
On the other hand, for debugging purpose, it would make sense that the helper could also be used from the camera (since the ray can be casted from the camera). Anyways, enough with that now. I got what I wanted and thanks again for your invaluable input on this.
I guess in this case, you can use RayHelper, because I doubt you would benefit that much more from creating your own visible ray cast by custom line mesh. Also you would have to do a bit of work to get all the information that babylon ray cast and helper provide.
This should be the case if you set ray helper on camera.getForwardRay()?
I might give it a try later but lets just end this here for now. I don’t intend to use it at this moment but hopefully this discussion will make a starting point for someone facing with a similar use case.
. I believe this is the way to go. 
