# Is there a reliable replacement for the Quaternion math in blueprints?

Hey, I was messing around trying to convert the “physics gun” from the content examples map to have features similar to the stock gun in UE3, but I hit a snag in regards to orientation. The UE3 gun uses quaternions to calculate out the orientation of the RB Grabber, but quaternions are unavailable in blueprints. Is there a reliable replacement for the quaternion math available? Otherwise, I’d like to see them added as a variable type in the future.

Thanks!

I’ve never worked with UE3 (And pretty new at this in general), but isn’t it just the rotator you’re after? You can get an actors rotator, and get directional vectors etc.

I think in the background the Rotator (sometimes in blueprint referred to as Rot) is in the background actually a Quaternion, but since most people don’t feel like doing math with Quaternions, the only show Euler angles. Even if you break a Rotator it will output the Euler.

So in short, try using the Rotator functionality for anything you want to do with rotations.

We don’t plan to add Quaternion support to Blueprints because they are quite complicated to enter and create from components, whereas Euler angles (Rotator) make quite a lot of sense to break apart and put back together. We did however expose several maths functions which convert to quaternion under the covers (e.g. ‘Combine Rotators’ and ‘Negate Rotator’ nodes). You can also use a Transform which stores the rotation as a quaternion internally.

Isn’t Rotator already a Quaternion internally? Since a Euler could just be stored in a Vector.

Rotator is stored as Euler angles. As you say it is basically just a vector, but we keep it as a separate type to make things more clear.

Ok! Thanks for the info

The only problem with Rotators is gimbal lock. It is literally unavoidable and really becoming a critical issue in VR, where you can look straight up or straight down (these are the most gimbal-lock-prone points). Man I am sick of it already. In C++ you can workaround many cases of gimbal lock by converting them into Quaternions (even, though, most of the rotations are still stored as rotators, such as ViewRotation or ControlRotation); no such luck in Blueprints. This really should be addressed if you are seriously targeting UE4 for VR (and you better do!)

Gimbal lock is really annoying. Can we get Quat support in BP now? We’ve been good

Have this issue right now. It’s time Epic gave us an Advanced Exposed Blueprint API for those who wish to use it. I think we have earned it by now.

Yeah I’m completely blocked by this. Makes sense to hold people’s hands if they don’t know how to use quats and matrices but many of us do

We shouldn’t be fighting for native Quaternion support. Quaternions should be the baseline. I am assuming by now this support is in there?

Hello ! Blueprint node “Combine Rotators” is in reality making a quaternion rotation !

Here is the proof : When you call this node, it converts both rotators to Quaternions (FQuat), multiplies them, and returns the result as a Rotator !

Hope it helped

Bump! I need quaternions too.

Double bump

Okay so I think what JamesG (https://answers.unrealengine.com/users/98/jamesg.html) was saying is that although Quats are not a Blueprint variable type, you can feed Euler-based Rotators into certain math functions such as CombineRotators and NegateRotator, and it will calculate them using Quaternions to output a new transformed Euler-based Rotator that didn’t get gimbal-locked (did I understand that correctly?)

He says you can store rotations in a Transform, which stores them internally as Quats, and I think you feed that Euler angles too. So basically in Blueprint it sounds like you cannot create or edit Quaternions, but you CAN get equivalent Euler angles without gimbal lock issues by doing all your rotator transformations via the math nodes that use Quaternions internally. You input Eulers to them and they output Eulers, but they use Quats to calculate so they should avoid gimbal lock. It’s blackboxed but you can used it to get the same results. Did I understand that correctly?

Triple bump

You don’t get the same results. If you have several stages of operation in which the variable passes through the rotator variable type (aka, it comes out of any of those functions) you are immediately welcomed back to gimball hell.

Darn. I was hoping…