Have collision groups allow player to walk through, but not put camera through part

I have these doors with a part in them that’s CanCollide false, so the player can’t get their camera to look behind them. But when I add a collision group to allow the player to pass through the door, it also allows them to look behind it with their camera. How can I prevent this?

Trying to look behind with camera doesnt work, cool, but can’t get through the door

Can look through with camera, not cool!

I don’t want this!! I need the player to be able to walk through the door, but not allow them to get up to the door and look behind it

1 Like

Is the player supposed to enter the house and roam around its interior? Or it would teleport him to another area as soon as he enters? If the 2nd question’s answer is yes, can’t you simply put a part behind the yellow glowey part to prevent the camera going inside?

Player is supposed to teleport. However, i wanna do like an animation showing the player entering the house, then ui screen pops up as player i steleported

For this solution to work, you’ll need to fetch the PlayerModule and parent it to StarterPlayerScripts located in StarterPlayer.

So I myself experienced a similar problem, just with spheres. I wanted to be able to see through them, even though they were visible and had CanCollide set to true, a friend of mine taught me a way to customize the CameraModule, so here we go.

You need to first fetch the PlayerModule obviously, and parent it to StarterPlayerScripts. To do this, go into play solo in Roblox Studio with the explorer open, find StarterPlayerScripts and there you should have PlayerModule. Now copy PlayerModule, and then stop the play solo. Now paste the PlayerModule into StarterPlayerScripts, and now we can actually begin with the actual solution.

Find a module called “Popper”, which is in ZoomController, in the CameraModule. Open it up, and you’ll see the description of it is “Prevents your camera from clipping through walls.”. Now do
Ctrl + F and find the function canOcclude. Now you’ll find these comments,

-- Occluders must be:
-- 1. Opaque
-- 2. Interactable
-- 3. Not in the same assembly as the subject

you can ignore these comments. I assume it’s when someone wants to edit them at Roblox.
Let’s focus on what it returns. It should return a bool. If the bool returns false, it should clip through the object of the argument. If you return true, it doesn’t clip through. Now I’m gonna use .Name for this,
however what I’d recommend would be that you use CollectionService to tag certain objects as CanOcclude, so that you can’t clip through those objects. This script will check for the .Name from the passed object to the function.

return part.Name == "ObjectNameHere" or 
	getTotalTransparency(part) < 0.25 and
	part.CanCollide and
	subjectRoot ~= (part:GetRootPart() or part) and
	not part:IsA("TrussPart")

What this does is to check the part.Name, and if the part’s name is “ObjectNameHere”, it will return true, and it won’t clip through the wall, otherwise it lets Roblox do their normal checks.


Wouldn’t that cause problems later on tho? Ik in the oast forking other stuff like the chat, etc. can cause game ruining problems when Roblox decides to update these

I’ve forked the CameraModule in the same way as shown here in one of my games, which at this point is over one year old and it’s still functional. It may cause issues later on, like from 1-2 years from now if Roblox decides to do another major revamp to the PlayerModule. I doubt it’ll break though, because it’s simply forking the PlayerModule and then parenting it to StarterPlayerScripts. This should preserve the current version of PlayerModule, and when it recieves updates it won’t actually update. Point is, it has the potential to break like any of your scripts if Roblox decides to do a major change. Usually Roblox notifies you in good time when they are deciding to do major changes, source:

1 Like