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).
Doesn’t appear to be the same issue that we’re experiencing, but looks to me like it’s probably from the raycasting update as well.
Our team lead was able to post a formal bug report here: Humanoid "bounces" or floats up when standing still [only in-game, can't replicate in Studio]
Hopefully this can all be resolved soon.
When debugging I cannot get the results now from raycast (it says can’t convert to string). Can only be viewed if you write raycastResults.Instance in ‘watch’. If it could please be fixed, makes debugging harder.
Hey, when working with RaycastParams.FilterDescendantsInstances
It would not accept any argument introduced to it via table.insert
Is the behaviour intended?
Thank you.
Hey @subcritical @tnavarts,
in the same vein as @RuizuKun_Dev, I am receiving issues with raycasts hitting impossible places. I confirmed this by calculating the distance of the hit point from the actual raycasted line - in normal scenarios, it should never exceed 0.01 studs, but in some cases it exceeds 1 stud.
I have made the most minimal repro file I could, but the issue only seems to occur when raycasting in bulk by the looks of it, as raycasting from the exact same positions doesn’t work.
I have created a thread on it but it gained no traction, and as this bug is very dangerous for games, I’d appreciate any sort of support in regards to it:
Blacklist/Whitelist are taking the same times for me in a 5000 part moving assembly area.
Is the raycast now just naive cast and then checked against the blacklist? Old form had performance benefits to using a whitelist only iirc. Or do physics updates force updates on raycast, even if its from parts ignored?
This is a serious performance issue for me, with 15 rays/frame. The first RaycastBroadphase takes wayy too long, at 2.3ms on a 3070. The subsequent ones being negligible (~.05ms less).
EDIT: Example:
(“fat ray” being a user profile just encompassing the raycast call)
Is there any reason that worldroot:Raycast() will return nil if it hits a MeshPart further than 2k studs, but will return the hitPart if it’s a normal Part?
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.