Less hacky way of creating a ViewModel?

tl;dr: Goal - make a ViewModel that can be animated, clothed, and one that doesn’t collide when you zoom in first person.

Hello! I am in the process of creating a ViewModel for my first-person based game. Currently, I have created the ViewModel using EgoMoose’s tutorial (The First Person Element Of A First Person Shooter). Basically his ViewModel is a rig whose head’s CFrame is set to the camera’s CFrame every render stepped. In the rig, aside from the head, there are arms, the UpperTorso, and the joints. All of the base parts have their CanCollide set to false, and the head’s anchored property is true. This allows you to zoom in with the ViewModel without collision from any parts of the rig.

The problem comes in when you want to animate and clothe the ViewModel. Since there is no Humanoid, you cannot animate it, unless you add one in. However, by adding in a Humanoid, the Head and UpperTorso are forced to have their CanCollide property set to true (idk why, that’s just what I observed), causing collisions. I believe it has to do with the Humanoid’s RootPart property, which is dependent on the type of rig you’re using (ie. the RigType property. When you set the RigType to the correct rig you’re using, the RootPart property is set). From my observations, the RootPart is automatically set to the HumanoidRootPart (duh), but it can be set to the UpperTorso (on R15) if the HumanoidRootPart does not exist (in my ViewModel, the HRP did not exist, so the RootPart was the UpperTorso). When the Humanoid’s RootPart property is set, all of the other base parts in the rig have their CanCollide properties set to true, causing collisions. It seemed the only way to keep a humanoid in the rig and prevent collisions was by somehow preventing the RootPart from being set.

Fortunately, there are some ways to do that. If you set the RigType to R6 when you are using an R15 rig (and vice versa), the RootPart property is not set. Thus, you can animate and zoom in without collisions, however, because the RigType is incorrect, you cannot add shirts to the Rig. As a side note, when you set the RigType to the RigType you are using, you get around the shirt issue, and you can animate, but you are going to have collision between the ViewModel and the character when you zoom into 1st person because of the reason I mentioned in the previous paragraph.

Another way to prevent the RootPart from being set (and the method I am currently using) is by creating your ViewModel (and, in my case it was just a Head, the arms, the UpperTorso, and the Humanoid; the RootType is automatically set to UpperTorso) and renaming what would be the RootPart to something else. I changed the UpperTorso’s (which would be the RootPart) name to UpperTorso2. As a result, the RootPart wasn’t set, and I could animate, clothe my character, and avoid collisions.

But wait, this sounds like a huge win, doesn’t it? And why did I say this method was hacky?

Because I renamed the UpperTorso, every animation I create also has to follow this naming scheme. I need to make a separate rig whose UpperTorso is named “UpperTorso2” in order to make animations for my ViewModel. This means if I can’t use the same animation for the ViewModel and for the character, doubling the amount of animations I can make.

Do you guys know any better ways to create a viewModel that you can animate and add clothes to, while avoiding collision when zooming into first person?

Apologies for the long post, and thanks.

3 Likes

I had this problem myself a while ago and I found a work-around using Collision Groups, here is a file containing my ViewModel and solution:

ViewModelRepo.rbxl (76.9 KB)

7 Likes

If you don’t want to animate with a Humanoid, Just use Animation Controllers.

1 Like

Good idea; however, I don’t think you can clothe the rig without a Humanoid. https://www.google.com/url?sa=t&source=web&rct=j&url=https://scriptinghelpers.org/questions/54253/how-do-i-put-clothes-on-non-humanoids&ved=2ahUKEwiphvCd6KjmAhXhT98KHcL0A-4QFjABegQIDBAH&usg=AOvVaw3PaJC46XDntLQyW_VYNb9u

Great Point! I think that @ValueChanged’s solution is the best solution for this case, then.

1 Like

Excellent idea (haven’t tested it, but I will soon lol)! Do you think a NoCollisionConstraint would be better for this situation?

1 Like