Upgraded, Improved, and Faster Raycasts

[synical4 (Synical)]

I need this so bad for my fighting game lol. Currently all “hitboxes” are just a ray from the humanoid root part forward however many studs the attack is. This causes issues when it comes to hitting enemies when you aren’t directly facing them. I completely support this idea

[subcritical]

Shapecasts are definitely on our radar

[Pokemoncraft5290 (Based)]

Out of curiosity, if you were to implement shapecasts, how much faster do you think they would be compared to a luau implementation?

[herfave_wastaken (herfave)]

Been advocating for shapecasts for 4 years now… One day the dream will become reality, until then we cast tens of hundreds of rays at once.

[Hexcede]

@kaiyellow2008

May I ask what a shape cast is exactly? Judging by the name Im thinking its a raycast but instead of a ray its a shape

@herfave_wastaken

Been advocating for shapecasts for 4 years now… One day the dream will become reality, until then we cast tens of hundreds of rays at once.

Shapecasts, at least, Sphere (sometimes called a capsule cast, is basically a raycast with a radius, typically as two points and a radius, and its like two spheres and a cylinder), Box (like Region3s but they can be rotated and aren’t fixed to 4x4x4 voxels), and via part bounds are on the roadmap and are being worked on in the engine:

@kleptonaut

On the roadmap.

The big raycast API overhaul set the stage for this!

@Maximum_ADHD

Added Function Objects WorldRoot:GetPartBoundsInBox(CFrame cframe, Vector3 size, OverlapParams overlapParams = OverlapParams.new())
Added Function Objects WorldRoot:GetPartBoundsInRadius(Vector3 position, float radius, OverlapParams overlapParams = OverlapParams.new())
Added Function Objects WorldRoot:GetPartsInPart(Instance part, OverlapParams overlapParams = OverlapParams.new())

GetPartBoundsInRadius wouldn’t be a typical spherecast (its like a spherecast with both points at the same exact position, not sure if that’s a communication issue or intended), but, the typical behaviour could be recreated with two of those calls and a GetPartsInPart call. Additionally, I think GetPartBoundsInRadius/Box is actually meant to be GetPartsInRadius/Box

But, all of that will hopefully be worked out by the time it all releases. (@subcritical dunno if you know anything about that, or if that should be noted)

@Pokemoncraft5290

Out of curiosity, if you were to implement shapecasts, how much faster do you think they would be compared to a luau implementation?

Well, technically there are no luau implementations. You would need access to collision geometry. However, the most common approach is to use :GetTouchingParts() which is typically very slow, and relies on CanCollide/collision group info unless a Touched event is connected.

It’s hard to really give a good benchmark on this without proper data on my part, but, connecting a call to this on Heartbeat for a complex part resulted in very poor performance, somewhere around maybe 20 or 30 milliseconds each, which, was getting me about 30 frames (normally I sat closer to 150 in the game I was testing this in)

[RuizuKun_Dev (Kitsune)]

Does this mean BasePart | Roblox Creator Documentation will be coming soon as well?

(Iirc this toggle means Raycast can / can’t hit the BasePart)

New Part Collision Property: CanQuery - Now Available!

This feature is now enabled everywhere as of 1/5/2022 A third collision option is now added to compliment CanCollide and CanTouch, called CanQuery. CanQuery This property lets you determine if the part will be hit by spatial queries, such as raycasts or bound overlap checks. A part that has CanQuery set to False will always be ignored by spatial queries, even if the part is whitelisted. CanQuery can only be set if the part also has CanCollide turned off. It will be hidden in the Properties w…

unless it’s already been enabled? I don’t remember that

[jiwonz (Developer_Jiwonz)]

Ray casting is used a lot in Roblox, but I was reluctant to do it befause of the lag on slow computers due to performance issues, but I think this update is very interesting and good! and I wish there was a performance update to the gravitational physics bullet system(continuous raycasting method with render stepped) I’m using! Thanks to Roblox.

[xChris_vC (Chris)]

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

[anon43684807]

(post marked for deletion for privacy reasons)

[Haikei]

Very helpful, great timing too.

[SquarePapyrus12 (square)]

will this also be available for FindPartOnRay functions?
i personally find them better than the new raycast functions

[SynthetickDev (Syn)]

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.

[tnavarts]

@SquarePapyrus12

will this also be available for FindPartOnRay functions?
i personally find them better than the new raycast functions

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.

[Etheroit]

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).

[subcritical]

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.

[TheCraneStyle]

@colbert2677

apecasting would be really good for our use case since we have mesh deformed enemies as well as enemies that perform large scale attacks. Since we don’t have shapecasts, we need to rely on other methods: several hundred or thousand raycast points, Touched (sort of ew to rely on physics for hitboxes), information from Bones to create raycast points and so on.

Our current method of slapping attachments all over the enemies isn’t sustainable in the long run and it’s slightly tedious to set up, especially with mesh deformed rigs. It’s al

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.

[TheCraneStyle]

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?

[Forcoy]

Im pretty sure you can change the limit for a raycasts distance

[MrChickenRocket]

Add CanCollide as a filter parameter for WorldRoot:Raycast

Problem: Doing checks to see what players can collide against with WorldRoot:Raycast is currently difficult, because raycasts ignore parts CanCollide property. Often CanCollide == false geometry gets used for triggers, effects, and other visuals, and players automatically do not collide with them, which makes building relatively simple. To have a raycast check the same geometry that players can touch the options are: manually casting the ray twice or more (example below) building/maintainin…

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…

[Tobycon]

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