Are rays supposed to have a fixed length when doing raycasts?

Help and Feedback Scripting Support
#3

This is the first thing I noticed when the API came out. I probably complained about it, somewhere.

2 Likes
#4

It does the same thing for me as well.

1 Like
#5

I just noticed that I typed workspace:FindPartOnRay(ray.Unit, debugPart) instead of workspace:FindPartOnRay(ray, debugPart). Its the same thing either way, I was just testing to see if it made a difference.

#6

The max distance seems arbitrary. I think it’s OK as it is right now. Adding an extra parameter for the “length” of the ray would be cool, though.

#7

I think there should be a constructor overload that uses a CFrame and a length that defaults to 5000.

4 Likes
#8

I had a MASSIVE issue with this when trying to make a special camera system a while ago.

Sigh.

Here’s the post I made about it:

3 Likes
#9

I’ve been thinking about this lately. This is a pretty important issue from an API usability standpoint, and there’s more than one way we could tackle it:

  • Make it easier to set the length of a ray
  • Make raycasts use an explicit distance param instead of the length of the ray

I’m leaning towards the latter.

Changing raycast behavior would probably mean adding a new API to avoid breaking existing games. This could be an interesting opportunity to move the raycasting API out of workspace and clean up some legacy stuff. We’ll see.

15 Likes
#10

Came across this a couple weeks ago and it gave me such a headache. I made a debug part then noticed what was actually happening. Definitely a bug in my eyes.

#11

I’d love to see an overhaul to the current raycasting system. Having 4 returned values in a tuple and several methods for handling blacklists/whitelists seems clumsy if you ask me.

6 Likes
#12

It definitely is quite clumsy, but on the other hand the countless scripts breaking if this was changed seems like a lot of collateral damage to just accept for making something a bit easier to use.

#13

The old system wouldn’t need to be changed, just deprecated.

1 Like
#14

Seemed like a nuance of not replacing the existing thing but instead adding a new method is in order there though. A new method that does take these things into account I would definitely support of course.

#15

What I’m thinking at the moment is a specific “Raycast” object.

It would have an integrated white/blacklist, a CFrame that could be changed, and then read-only result fields that are updated when a raycast call is made using the object. It could also have property filters, and perhaps it could also pick up Humanoids specifically.

The question comes down to how optimal a system like this would be.

4 Likes
#16

Raycasts traditionally only need an origin and a direction. Can you elaborate on what you mean by a CFrame?

#17

Well, it has more to do with the annoyances in the current Ray API.
A CFrame could define both the origin and direction (via lookVector). The object could also have a Vector3 Position/Direction property that reflects between the properties.

#18

I had always assumed the reason for this was because of an optimization. I have no real evidence to back this up (since I’ve never seen the internal code), but it makes sense from an intuitive perspective at least if I were writing a ray class.

If the method for ray-casting was to find all intersections with geometry an obvious optimization would be to use a 3D tile like system and only pick the tiles that the ray passes through. That way you aren’t testing against geometry the ray has 0% chance of hitting. Since rays are world space it would make sense to define these tiles (or a reference to them) when constructing the ray as opposed to generating them every time you want to do the geometry intersection check. In other words the tiles never change, only the geometry inside them.

From there it would then make sense to return a unit ray as the default so that tons of tiles aren’t being calculated for no reason.

In an ideal world however I think the best solution is to just (as other people have suggested) add a new parameter.

Once again though I’ll stress that I have no idea if that whole tile concept is true so this is purely a guess…

3 Likes
#19

One other thing I think a Raycast object could be beneficial for is garbage collection.

The current system of white/blacklists requires us to store the objects in an array. If we want to have a persistent array, then we have to manually remove the objects from the array in order to free them from memory, or just construct a temporary array each time we want to filter them. Either way, it’s a massive annoyance.

Even Roblox’s camera code has to deal with this in the PopperCam, because it has to ignore both the vehicle the player is in (if any), and the characters of every player in the game. It tries to optimize as best as it can, but it ultimately requires two arrays to be concatenated every time because regulating the contents of the array is already annoying as it is.

local ignoreList = {}
for _, character in pairs(PlayerCharacters) do
	ignoreList[#ignoreList + 1] = character
end
for i = 1, #VehicleParts do
	ignoreList[#ignoreList + 1] = VehicleParts[i]
end

A raycast object could open up the opportunity to improve this on the backend. The references to these objects could be stored in a lookup dictionary with weak_ptrs, thus removing the need for developers to manage the object references.

Any thoughts @Fractality_alt?

1 Like
#20

All aboard the “FindPartOnRayWithIgnoreListAndSetDistance” hype train :slight_smile:

In all seriousness though, if you’re considering adding new raycasting API, consider exposing them in GeometryService, as workspace is getting crowded and the raycasting methods are defined in there anyway.

#21

we need this too

1 Like
#22

Just curious to know if anyone has looked into this issue since then, as it still seems to be happening.

1 Like