From my experience it really depends on how you use it. For example, a large filter descendants lags significantly more than a short one. After switching to the new API I haven’t observed a noticeable difference in performance. However, if you benchmarked the functions I’d probably expect the new one to be a tiny bit faster, and reusing the same raycastParams is very useful and probably better for performance than creating new Rays every time. Can’t confirm this though.
Agreed, this seems like a massive waste of resources and a cause of unnecessary confusion. This is off-topic but that’s only the fault of whoever decided to start this “initiative” that will be rolled out all at once without consulting developers in a specific thread first.
Instead of getting worked up on a boatload of assumptions when we don’t even know what such a change is going to look like, perhaps let it roll around first and wait for the separate announcement on the topic. (since we get an announcement for any significant API change – it’s not like they would be “oh but I mentioned it in a completely unrelated announcement as a side note, it doesn’t need an announcement”) Doubt they would deprecate huge parts of the API suddenly.
Also when any engineer at any company mentions “it’s being worked on” you should probably think in the order of many weeks / several months, not a shorter time scale than that. Engineering is typically very slow and methodical.
1 Like
The new function should be very slightly faster (Since you can use the same RaycastParams over and over again rather than having to construct a new ray with Ray.new every time), but in most practical cases actually doing the raycast is the expensive part, not the Lua interop, so you won’t see a noticeable difference.
If you had a very large ignore list, and you reuse that ignore list between calls with the same RaycastParams now, then you could see a larger performance improvement.
And if you structure your code such that you use Collision Groups for hit filtering, then you could potentially see a very large performance improvement, since that entirely removes the need for allocating and modifying ignore lists.
Will there ever be a “faster” Raycasting, if that is even possible?
Like “Ray caching” between callbacks. The first callback is the most expensive, the next ones are less expensive.
I know there was discussion earlier about this returning nil, and that it was intended, so how would I go about using this to find the end point of the ray?
Also, whats the difference between this and
local PS = game:GetService(“PhysicsService”)
local part, pos = workspace:FindPartOnRay()
local group = “CollisionGroupName”
if not PS:CollisionGroupContainsPart(group,part) thenend
because in my opinion, just like using the TweenService, it will be very tedious to keep making new RaycastParams every time I want to change how the ray will interact with the game.
@tnavarts, The ignore list isn’t mutable, so if the list changes you’d have to create a new RaycastParam anyways, I don’t really see the point of using it, and using CollisionGroups instead of an ignore list is probably not a good solution either since it causes complications, you can only pass one CollisionGroup and CollisionGroups can’t be created on the Client which is where I do Raycasting thus this causes further complications.
1 Like
I feel like we should be able to set arguments for RaycastParams.new() like TweenInfo.new(). It feels really awkward having to create it then change individual properties later.
You don’t actually have to create a new RaycastParams if all you want to do is modify the ignore list. You can modify it the same way you create it:
RaycastParams.FilterDescendantsInstances = {unpack(additionalItems)}
Though, @tnavarts, it would be slightly more handy to have the array be mutable, as adding a new instance to it would be as simple as doing table.insert( RaycastParams.FilterDescendantsInstances, newItem). At the very least I think an error should be throw when trying to do this as I wasted quite a bit of time trying to figure out why my rays weren’t working properly.
1 Like
I considered having a way to something like that when I designed the API, but (ironically given you complaint) I was worried it would be too easy for people to accidentally “leak” an ever-growing ignore list which they never cleared out.
Locking the returned table so that you can’t accidentally insert into it thinking you’re modifying the RaycastParams would have been very unconventional, as no API calls currently return a locked table. Either way, we can’t change the API now whether or not it is actually a good idea because people might already legitimately be getting the ignore list and using the table for their own purposes.
I can look into adding a lint for this scenario though, so that the studio script editor would warn you if you try to do that.
1 Like
Will it be so we can pass multiple collisionGroups anytime in the foreseeable future? As stated we can only pass one currently. My case is narrow and there is no easy alternative.
My game has characters swim in terrain water. The Humanoid makes arms canCollide true when in water to let physics, buoyancy, work on them. If a player fell with their arm tucked along a thin vertical wall into water their arm would then pin them to the wall as it would still overlap just having become cancollide.
I ended up giving the arms and legs a nocollide group so this could be fixed, but now I want to make a mouseoverShowName and it ignores their arms. I can’t just raycast each collision group individually, the wall wouldn’t be in the nocollide scan, nothing would be.
There’s no need, you can accomplish anything you need to with only one group.
The solution that you’re missing is that you can make a dedicated “raycast” collision group to use for the raycasts. If you do that, you can set exactly the set of collision groups which the ray to collide with while not impacting your other gameplay which depends on collision groups.
3 Likes
Was making RaycastParams an object necessary? Why not a plain table? Honestly this is one of my biggest gripes with TweenService; you have to make a TweenInfo object to pass into TweenService:Create(). This is going to be especially annoying since the RaycastParams constructor doesn’t take any parameters and all the properties have to be set individually.
Yes. If it were a plain table you would have to reflect the whole ignore list over to the C++ side every time, because there would be no way for the API to know whether the table contents had changed since the last call. Vs with a RaycastParams object the ignore list only has to be reflected at the time you assign it, and it’s stored inside of the RaycastParams struct on the C++ side afterwards.
2 Likes
I think you now broke all games that using all these functions,
I don’t really like this update, I don’t even know how to fix my gun because my gun using RayCasting Function.
1 Like
None of the existing functionality was changed or turned down. It’s just marked as deprecated. Please read more carefully before posting. If your code is broken then there’s another reason for it, use #help-and-feedback:scripting-support if you get stuck.
4 Likes
I noticed that the ClosestPoint method of Ray is unavailable with the new raycasting functions. This is essential to my game. Is Ray being deprecated, and if so when will this function be ported?
2 Likes
Ray is not being deprecated.
3 Likes
Is there any possibility of this behavior changing? The old raycasting API supported finding the position even if there was no part detected, while the new API doesn’t return anything if it doesn’t hit a part. The old behavior is actually more useful (see FastCast), and it’s the one thing stopping me from using the new API entirely.
1 Like
If there was no part found, isnt the only useful piece of data the end point? Which is just origin + direction?
4 Likes