Although I understand what It does, I end up thinking of it like this:
if x > 0 then
return 1
elseif x < 0 then
return -1
else
return 0
end
or a more simpler version:
math.ceil(math.clamp(x, -1, 1)
-- not really, as it rounds up, and not up and down, but i think you get my point
But thats not what I’m wondering about, I wondering about when I should use it, because I have been playing around with it for a little while, and I want to know about a proper use for it?
Only thing I can think of is logic, 0 being nil, 1 being on, and -1 being off, or a rounding system to check if it’s positive or not
I can’t think of other uses for it tho
Sometimes calculations are easier when you ignore a number sign, so it’s useful if you want to do calculations and add back the sign at the end(math.sign(x)*result).
I used it in only very specific case scenarios. I cannot say you will ever need it.
One is for my turret module to detect the correct quadrant. The issue was
local lookAtWorld = CFrame.lookAt(turretPosition,lookAtPosition,baseCFrame.UpVector)--goal LookAt CFrame, generates accurate correct CFrame,
--but quadrants get confused since it uses the gunbarrel position
local lookAtWorld = CFrame.lookAt(turretPosition,lookAtPosition,baseCFrame.UpVector)--goal LookAt CFrame
local goalCFrame
if self.Constraints then
local turretRelativeCF = baseCFrame:ToObjectSpace(lookAtWorld)
local x , y , z = turretRelativeCF:ToOrientation()
--print(math.deg(x),math.deg(y),math.deg(z))
local constrainedX , constrainedY = self:EulerClampXY(x,y)
--Detect quadrant of lookAt position
local jointPosition = currentJointMotor6D.Part0.CFrame*originalC0Position
local quadrantLookAtFromJointPosition = CFrame.lookAt(jointPosition,lookAtPosition,baseCFrame.UpVector)
local baseRelative = baseCFrame:ToObjectSpace(quadrantLookAtFromJointPosition)
local _,y, _ = baseRelative:ToOrientation()
constrainedY = math.abs(constrainedY)*math.sign(y)--use the quadrants of the lookAtFromJoint
--print(math.deg(constrainedX),math.deg(constrainedY))
--print(math.deg(constrainedY))
goalCFrame = relativeToWorld*baseCFrame*CFrame.fromOrientation(constrainedX,constrainedY,z)*turretCFrameRotationOffset
else
goalCFrame = relativeToWorld*lookAtWorld*turretCFrameRotationOffset
end
This fixed this bug explained on this post:
Getting the angle between, signed in order to determine the directionality of spinning motion, I believe this is the most applicable since vectors are used a lot in a 3D game engine:
Something more advanced which I completely forgot for my CCDIK Module, I’m guessing its used to align the axis:
local jointRelativeCFrame = axisCFrame:ToObjectSpace(currentJointCFrame)
local swing, twist = twistSwing(jointRelativeCFrame, twistSwingAxis)
local axis, angle = twist:ToAxisAngle()
local axisSign = math.sign(axis:Dot(twistSwingAxis))
axis, angle = axisSign * axis, axisSign * angle --make the signs relative to twist axis
angle = math.deg(angle)
local x = -1
local result = x * 5 --it's -5 obviously
print(math.sign(x)*result) -- according to this, math.sign returns -1 now and if we multiply -1 with our result (-5), it prints positive 5. But here, original sign was negative in x, after this calculation, it became positive. So we lost our sign.
Hmm, so I don’t think this can be used, as I showed in this. This would make our calculation even worse in this case. If I’m telling something wrong, please let me know.
For that use case, it’s true that using the math.sign function wouldn’t be useful. However, for more complicated cases where you have to use logarithms for example this is particularly useful. A good example of this is my number formatting function: