I’m not quite sure what you said but I’d just want a parameter where I input the instances that can be hit and one for terrain and terrain water.
I’d like to be able to have terrain as a whitelist. Use case:
Player placeable buildings. Can be placed on top of players, animals, paths, other buildings (replace), items, etc (pretty much everything in the game). The only placing requirement is that it has to be on the ground (terrain). I’d use a raycast whitelisted to terrain to check this. Water should be optional because while I might not want the player to place a house on water, I might want to allow them to place a dock on water.
2 Likes
For your last point about water, it’d probably be more helpful in that case if it just gave you the material it hit. You probably won’t want to place buildings on the seafloor. 
Some buildings can optionally be placed underwater (e.g. lighting) or may be forced to be placed underwater (such as fishing traps). In the case of the optional, I could just ignore water altogether. In the case of forcing it to be underwater, I’d first cast a terrain ray including water to make sure the target was in the water, and then I’d cast a second terrain ray ignoring water to find where exactly the object should be placed.
Yep, so you probably want both options. 
whoops didn’t mean to reply to baa_aaa
This is it being the inverse of FindPartsOnRayWithIgnoreList:
local part, pos, mat, norm = workspace:FindPartOnRayWithIgnoreList(ray1, {workspace.RayDraw}, true, true)
drawSegment("Blacklist", ray1.Origin, pos, BrickColor.new("Black"))
local part, pos, mat, norm = workspace:FindPartOnRayWithWhitelist(ray2, {workspace.PartWall}, true, true)
drawSegment("Whitelist", ray2.Origin, pos, BrickColor.new("InstitutionalWhite"))
The other way of doing it would be to expose a method on the C side responsible for doing raycasts behind the scenes. This method takes an array of primitives and determines whether or not it collides with each of them. The positives to using this method would be
- performance would be based on how many parts are in the whitelist (on the flipside if you put workspace as the whitelist rip)
- no max distance would be needed, allowing you to go over 1000 studs without using multiple rays
But due to how that method behaves, you wouldn’t be able to use it with terrain.
- Does terrainCellsAreCubes affect smooth terrain? If not, it probably shouldn’t be included in new API members.
- I like the first one because it’s clean and familiar, but the way you’re describing it makes it sound more expensive than an ignore list, which sounds backwards.
It sounds like we have two options–slow with terrain, or fast without terrain. I’ll refrain from posting that “why not both” taco commercial gif because that sort of redundancy can lead to confused users.
imo this is the right way to go. bonus points for exposing something that works exclusively with terrain.
1 Like
Not exactly. The way the algorithm for FindPartOnRay is implemented is designed to scale really well with the amount of parts in a level, and there should be no difference with adding a whitelist. The other however could either be really fast or slow, depending on what you provide as the whitelist.
Aight, FindPartOnRayWithWhitelist would make more sense in that case.
As of last release this was implemented as
Workspace:FindPartOnRayWithWhitelist(Ray ray, Array<Instances> whitelist, Bool ignoreWater)
Sadly it’ll be a few weeks before it can be enabled, as we have to wait for the mobile platforms to get updated to the latest version of the client.
It works the same way as I mentioned previously (minus the terrainCellsAreCubes parameter, which will be useless once blocky terrain is removed.)
3 Likes
I thought we couldn’t use FindPartOnRayWithWhitelist with terrain?
You will be able to use it with terrain. I went the route of mimicking the behavior of FindPartOnRayWithIgnoreList except ignoring the descendants of the instances in the table, it will only search for descendants of those instances. This works with terrain and water, and you have the option of ignoring water, like you would with the ignore list method.
1 Like
So to clarify:
- I can raycast with only parts in the whitelist
- I can raycast with only Terrain in the whitelist
- I can raycast with both Terrain and parts in the whitelist
- I can ignore water when terrain is in the whitelist
And to allow for that you’re using slower of the two implementations mentioned in post #27 (not the exposing of the C side method)?
This is really late, but how feasible would it be to make FindPartsOnRayWithIgnoreList change its behavior based on input? If Terrain wasn’t in the whitelist, it would use the faster method that only checks parts. If Terrain was in the whitelist, it would use the slower method that includes terrain checking.
Correct on all points.
The method I’m using isn’t the faster or slower one, but the more consistent one. It’s the same one used by the other Lua exposed methods. Also another reason I adopted it over the other one that I forgot to mention previously is the descendants filter, which wouldn’t be possible with the other one.
It wouldn’t be feasible, or possible even to use them interchangeably depending on what input was given. As I mentioned, one doesn’t have a descendants filter, so there’s already that change in behavior.
2 Likes
Woohoo, this makes so many things easier.
Heck yessss.
Also, Region3 whitelist when? From what I’ve heard,Region3 with blacklist searches through every part in the game to find the ones within its area, and cutting down on that could help a lot.
1 Like
Oh heck yes. Whitelisting for Region3 would be amazing. I wanna use it for certain things but it’s too intense 
FindPartsInRegion3WithIgnoreList does not search through every part in the game. It finds parts in the same way as FindPartsInRegion3. Are you having bad performance with it?
It’s almost the same issue as Raycasting with a blacklist. If I raycast with a whitelist using a blacklist, I have to continually re-cast whenever I get a bad value that I want to ignore. With Region3s, I don’t have to re-scan now that the limit is removed, but if for instance I wanted to do something like: “Paint all sidewalks in the blast radius green”, when I loop through I have to do an additional check to see if the part is a sidewalk – if it was a whitelist, I could skip that check.
Is there really a performance issue? I haven’t had any issues. But why expand your search when you already know what you’re looking for beforehand? It’d also be weird that raycasting, whose API is closely related to Region3’s, had an exclusive whitelist that wasn’t available to Region3 even though it was also applicable to Region3.
This is now enabled. If you have any issues with it, let someone other than me know (as I’m no longer an intern at roblox)
9 Likes