This is so useful for my raycast-intensive projects 
I use Raycasts for nearly anything, from weapons to NPC viewcones, from stepping out a vehicle to interpreting raycast results as a LiDAR system for autonomous driving (& pursuits)!
Can’t express how much I love this new update 
(post marked for deletion for privacy reasons)
Very helpful, great timing too.
will this also be available for FindPartOnRay functions?
i personally find them better than the new raycast functions
Whether this does apply to the old raycast methods or not, you shouldn’t really be using deprecated methods as it is bad practise and you always take the risk of them being removed at any time.
There is only one code path for raycasting inside the engine. FindPartOnRay vs Raycast just determines how much control you have over the raycast (E.g.: you can’t specify collision groups with FindPartOnRay), but the performance will still be equivalent.
Was there beta available in the studio for that feature? Asking cause I believe I had experienced some issues with raycasting not working with terrain properly last time I was messing with them (I used to have all betas enabled for some reason and disabling them fixed it).
We have some options to roll some pretty fast shapecast routines in C++ right now using vectorization and some of our internal acceleration structures. These structures might be challenging to expose to Luau scripts in a fast way.
Naturally, the perf gap between native C++ and Luau will get smaller over time as Luau gets faster.
Fun fact, while you would need to register what your casting for, you can implement a fairly performant shape cast by constructing the objects mathmatically. There are a lot of modules and or examples of the math so that you can construct almost any shape. From there, you could use a broad phase check to see if things are within range to qualify the mathmatical object intersection, and then perform the intersection tests.
At the moment I am also a fan of this, because you gain the performance aspect of not needing to have an invisible version of an object on the server for the collision that is auto replicated outward adding to packet strain. Since we can nto ditcate a Part created by the server into workspace as a “server only part.” While likely not as performant as something more built in, I can say from experience that the performance versus other methods I have seen are almost 10 fold.
Raycast thoughts:
I come from the mainstream industry, and one of my biggest concerns with the current implementation of Raycast is the returning of the Raycast on first valid intersect. And only getting one object returned.
Siting: Unity - Scripting API: Physics.RaycastAll
Siting: Using a Multi Line Trace (Raycast) by Object | Unreal Engine Documentation
In general the standards are:
→ Detailed Raycast ( segment behavior )
→ Returns all valid objects intersected in a table/Array in order of Intersection, with detailed information such as EntryPoint, Exit Point, Value from 0 - 1 represents where on the ray
→ “Tunnel Cast”
→ Similar to Detailed but removes all Detail data and instead returns all Valid objects intersected in the order in which they were intersected table/Array
That being said, also having a filter closer function pass through replace the current white list or black list feature Or be added to it. Would keep to similar closer pattern use like that in events, and such but in this case. The function will get the objects hit passed through it, and allow a return that only objects that return true are returned valid ( Yes this opens itself up to some levels of, if you make that function a heavy check its gonna be expensive and slow things down, but your kind of opting in on the complexity here, so it should adhere to the method implementation Philosophy of Roblox.)
That all being said, currently I get around all this by just using a custom Oct implementation that grants me these features, but “in theory” the performance increase of when players do “sweep” like checks, that currently would require them to recast the ray at each intersection hit and gather them up till it reached it end would be substantial.
P.s.
I do know that there are built in casts that are similar to the current implementation of Raycast, but these other types are very useful or IMO better than just having the single return on hit. But I do know that’s my opinion. Is there any looking in the future to providing these other standard implementation of Raycast behavior?
Im pretty sure you can change the limit for a raycasts distance
Just a bump for this feature request!
Right now it’s still unusually complicated/limiting to cast a ray that behaves exactly the same way a player would collide, which seems like an oversight 
Unfortunately the upcoming part.CanQuery doesn’t solve this, and it’ll matter even more when shapecasts come out - implementing a player controller will need raycasts that hit the same thing players do…
There’s something called raycast stacking where you fire multiple rays with the new ray origin starting where the current ray ends which means you can have rays that extend theoretically to infinity but this will probably lag your game before your ray gets that far.
I am currently using raycast stacking for my shooter game and I will still have to use it as to account for bullet drop which causes the arc in my bullets which cant be done with a single ray.
I also use raycasts a lot so glad there’s a performance improvement, thanks roblox
What do you mean? It’s a free performance boost for one of the most used features, especially in combat games.
I don’t have the Trust Level to post a bug report, so I’ll just put it here I guess.
Ever since this feature came out, we’ve had a lot of issues with our Humanoids’ ground detection.
Basically what we’re experiencing is that whenever a player approaches another object (really it can happen at any time, but it’s most reliable when standing next to something) they begin to float and/or bounce. It has had a large negative impact on gameplay (causes sight pictures to be incredibly unsteady), and I’m unsure what to do about it at the moment.
You can see this behavior here (YouTube, because it won’t let me upload directly): Humanoid Bouncing Bug - YouTube
And if you’d like, you can experience it for yourself in the live game: FLASHPOINT ALPHA - Roblox
I’m willing to provide any and all support necessary to get this fixed.
“most people don’t have a use for this…”.
What do you mean? Raycasting is an important feature used in almost all top games, even outside of Roblox, and this is a great performance boost for raycast-intensive games. Check the replies you will see how much people like it. It isn’t a boring update.
No matter what, you’re going to use raycast at least once.
Hello!
I use Raycast Hitbox for melee weapons in my game and they are currently not registering obvious hits that usually would before this update which lead me to believe that it has something to do with the new internal Raycast code.
I haven’t changed my Weapon code and Raycast Hitbox did not have any updates so I’m suspecting that this change is the culprit.
Is it possible to disable the new changes for my game so I can debug more effectively?
Interesting. Can you DM me a minimal repro?
I’ve received several bug reports in the same vein about wonky bouncy humanoids. I figure I’ll mention it, but it could be entirely unrelated.
It didn’t do this originally, and I’m unsure if it’s related to raycasting explicitly, as I only use the stock humanoid features (nothing custom).
