Help with coming up with an efficient way for dealing with Aim-offsets

Hello, as a lot of FPS programmers know (at least most) it gets very tiring eye-balling an aim offset for every individual gun!

That’s why I am looking for an equation (which would help a lot of people out with aim-offsets)

What I’m looking for is an efficient way that calculates the perfect offset for aiming when given a reference point which is an Aim-part (the part being where it should offset to). (utilizing standard viewmodels)

If you can help me with how I can possibly achieve this please share it! Thank you! :smiley:

1 Like

Can you explain what an aim-offset is, exactly?

Im guessing some sort of spread. Like how the gun becomes more inaccurate.

The aim-offset is a CFrame value that tells how the viewmodel should be lerped so it looks like the player is aiming down sights.

You could just try messing around with the CFrame value, just remember:

Positive Z = backwards
Negative Z = frontwards

Positive Y and Negative Y = Up and Down

Positive X = to the right
Negative X = to the left (not quite sure about this one cause I forgot lol)

EDIT 1: Fixed grammatical errors

I understand that but if I were to utilize that method then I would have to eye-ball it and keep adjusting the CFrame till I get the offset i want. I was wondering if there was a formula or something that would automatically get the offset utilizing a reference point (which is an instance that it should ads to)

Can you show me your not-aiming offset?

My system utilizes animations for positioning for idle animations and fire animations, etc . Here is what it looks like

https://streamable.com/s7vvuq

So if the gun is bigger, the “aiming offset” should be pushed backed to accommodate for the extra gun size. Am I seeing your problem wrong?

That is also a problem I have lol. But my main issue is finding the right CFrame to lerp to in order to position the viewmodel correctly to look like its aiming

If you have some reference part on the gun that says “this part should line up with the camera” you could calculate where the primary part should go like

local camera = workspace.CurrentCamera

local primaryPart = ...
local cameraAimPart = ...
local primaryPartOffset = cameraAimPart.CFrame:Inverse() * primaryPart.CFrame

local targetPositionForPrimaryPart = camera.CFrame * primaryPartOffset

I think that’s kinda what you’re asking?

1 Like

Yes, exactly what my issue is.

How does inverse help solve this problem? Just out of curiosity

1 Like

Imagine you just wanted to deal with positions.

Like, place the primaryPart such that it’s offset from the camera by the same amount that it’s currently offset from the cameraAimPart.

You’d just calculate the offset from cameraAimPartprimaryPart like

local primaryPartOffset = primaryPart.Position - cameraAimPart.Position

And then would add that position to the camera’s position:

local targetPositionForPrimaryPart = camera.CFrame.Position + primaryPartOffset

Done!

CFrames are extremely similar, conceptually. But they include rotations, so they don’t just have + and - operations.

The + becomes *.

Instead of -, you can * the Inverse() instead. For matrix multiplication reasons, the inverse goes on the left.

More info on the inverse: If CF is a CFrame that represents a rotation of 45 degrees clockwise and a movement of +5 studs on the x-axis. CF:Inverse() would be a CFrame that represents a rotation of 45 degrees counter-clockwise and a movement of -5 studs on the x-axis.

So I can think of Inversing a CFrame kind of like subtracting a CFrame from another to get the distance between that? Kind of like if you were subtracting numbers to see how far apart they are?

Yeah.

In the same way that a Vector3 can either be a Position, or a translation from A → B

local A = Vector3.new(...)
local B = Vector3.new(...)
local AtoB = B - A

-- now A + AtoB == B
-- and B - AtoB == A

In CFrame:

local A = CFrame.new(...)
local B = CFrame.new(...)
local AtoB = A:Inverse() * B

-- now A * AtoB == B
-- and AtoB:Inverse() * B == A
1 Like