EDIT I changed a lot of stuff and made some optimizations thanks to @suremark
also the actual problem sorta changed because i made a new faceDir var for hrp and made baseOffset relative to focusP instead of hrp pos
I really feel like these two lines are very optimizable but I’m not really sure how to go about it:
local diff = noPitchP-focusP
local camCF = cf(fromAxisAngle(normalUp:Cross(diff.Unit),pitch)*diff+focusP,focusP)
Updated version of post:
I need help optimizing this cframe math, the only limitations are that you cant get rid of Roblox’s functions completely and just do the math in lua (cause thats messy)
you can assume the following are constants:
normalUp (Vector3.new(0,1,0)
focusOffset (some vector3)
baseOffset (some vector3)
faceDir (some vector3)
p (some vector3 - specifically humanoid root part position)
yawOrientation (fromAxisAngle(normalUp,yaw) - where yaw is a float between 0 and 2pi)
pitch (float between -rad(80) and rad(80))
ignoreCutoff (table of ignore descendants)
local focusP = yawOrientation*focusOffset+p
local noPitchP = yawOrientation*baseOffset+focusP
local diff = noPitchP-focusP
local camCF = cf(fromAxisAngle(normalUp:Cross(diff.Unit),pitch)*diff+focusP,focusP)
cam.CFrame = camCF
cam.Focus = yawOrientation+focusP
camCF = camCF*cf(0,0,-cam:GetLargestCutoffDistance(ignoreCutoff))
cam.CFrame = camCF
if isLocked then
hrp.CFrame = cf(p,yawOrientation*faceDir+p)
end
You can just do focusP = fromOrientation(0,yaw,0)*focusOffset+p. This way you only have to create one CFrame for focusP instead of two.
Also, you can avoid computing hrpCF unless isLocked is true.
Other than that, I can’t think of any good optimizations for your code. Ideally, you should not really be creating any CFrames or vector3’s unless they are the end result. During intermediate steps you can just store the CFrame components and operate on them. Instantiating a CFrame or a vector3 involves taking square roots, which is expensive computationally.
Of course, if you need multithreading then ROBLOX’s CFrame methods are your only choice, but otherwise I’d only be operating on the components.
“Multithreading” in Lua doesn’t actually allow for parallel processing, because only one coroutine can ever run at a time. With CFrame and vector3 methods, you can input multiple arguments and they will be processed as a batch, according to the wiki. (Full disclosure: I am not a multithreading expert).
btw how do you go about coding cframe math? do you start off with the roblox methods then inline the math and simplify things out etc or do you not even write out your function with the roblox methods?
(assuming you are eventually planning to inline the math)
Basically I just make my own functions for things like Dot, Cross, toWorldSpace, toObjectSpace, and other things if needed. I store the CFrame components as variables and then I operate on them with those methods.
do you think it would be a good idea to bash out the math for a couple of things for the sake of better understanding cframes or do u think its not necessary?
I mean, if you understand what CFrames are and how to work with them, then you’ll be able to do these optimizations off the top of your head. It’s not strictly necessary, though–you could just look up the formula if you didn’t feel like mathing yourself out.
This thread has some info on what CFrames are, as well as some formulas for multiplying vector3’s by CFrames.
I think I have a decent understanding of CFrames but I’d like to take it to axisangle level XD
also Ive read that thread but tbh I dont remember it being particularly helpful
the videos about linear algebra by 3b1b i saw a while ago in this playlist really helped me
That’s a great playlist to watch. As far as taking your skills to AxisAngle level, basically what you want to keep in mind is that certain operations (e.g. square roots, or hashmap vs. array indexing) are more expensive than others, and that you want to minimize the amount of arithmetic operations performed.
Honestly, though, I wouldn’t be worrying a huge amount about optimizing the code for camera positioning unless you’re very tight on cpu resources. You only really need to run that code once every frame, and ROBLOX can handle stupidly many CFrame operations per second.