When in first person the invisicam system doesn’t ignore the character. This is due to a call to
local partsTouchingCamera = game.Workspace:FindPartsInRegion3(region3,nil,10)
which should be
local partsTouchingCamera = game.Workspace:FindPartsInRegion3(region3,Character,10)
Character is not ignored in first person with invisicam enabled causing an issue where in first person you can see your character’s body as invisicam glitches out with the the TransparencyController not updating every frame.
This only happens when running or when the character is moved a bit from the camera origin.
As in first person it finds parts parented to the Character.
Thanks for reporting this! This collision test was a last minute addition to fix another bug, where the camera could swing inside the bounding box of a concave mesh part, and not make the mesh invisible because all the rays originate from within the part. It was possible for the mesh to still have faces that are facing towards the camera, blocking the view.
I will have a look at how best to remedy this. I didn’t expect Invisicam to be updating at all when in first person, the TransparencyController should be what’s using LocalTransparencyModifier when the camera is really close to your character.
This is perfectly fine to do to get your game patched, and I’ll be discussing how we fix this in the core scripts tomorrow with @darthskrill. My choice of passing nil to FindPartsInRegion3 was deliberate and I’d like to avoid changing that if possible, because it adds the overhead of traversing the character model hierarchy on every renderstep, and that region3 shouldn’t be touching your character when Invisicam is running. The real bug here is that the occlusion modules (Invisicam and Poppercam) are not getting disabled when you scroll in to first-person. Both of these modules have significant cost from multiple raycasts, so disabling them will actually improve first-person performance of your game for players with lower-end machines.
If it turns out that the character can still intersect that region3 at the minimum distance where the occlusion modules are active because of huge wings, tail, festive narwhal, or something like that, I’d rather just skip that PartsInRegion3 check when the camera gets close enough to possibly hit these things.
Last week, I looked into this, and I ended up checking in an interim solution that includes your proposed fix, @Quenty. The long-term fix of disabling occlusion modules in first-person turned out to be a better candidate for my ongoing refactor of the camera scripts, since there are currently some minor differences between “LockFirstPerson” and scrolling in to first person with the mouse wheel, as well as an unhandled edge case if anyone were to set StarterPlayer.CameraMinZoomDistance to 2.0. I’m making all this work consistently and definitively, and will incorporate the enabling/disabling of all occlusion modules. Thanks for your help!
