Well the title says it all, on my journey through the blue abyss I have found that the basic operators for rotators are infact missing
Lina seems to have answered the reason why these operators dont appear in blueprint here. I still dont understand why the maths doesnt go on under the hood to make the front end more legible and not prone to issues like gimbal lock by automating the process of say converting a rotator to quat when certain operations are performed.
To elborate, I was performing a single once off addition of rotation on a single axis in a local space which is why I neglected to see the issue with world space cumulative additions on more than a single axis. Huge difference.
Combine Rotators does exactly that! Converts to quats, combines rotations, then converts back to rotator. We didn’t want to call that the ‘+’ node though, because people would expect that to add each element. If we add a ‘+’ node that adds each element, people tend to use that to combine rotations, and then it doesn’t work. A complicated issue! We may not have the right solution yet though… Sorry for the complications.
No its fine, I did have a minor complication using the combine node since it seemed to take vector inputs on the node itself. Im curious as to why we use rotators at all actually, I mean its nice for the frontend thats forsure but for the math behind the scenes.
I guess I feel that the conversion to quat should only take place when its actually required as modifying a single component of a rotation is simple float operations and all the conversion goes to waste. I dont know if theres a way to sense this stuff in blueprint to perform the appropriate action based on subsequent node wires.
This is from Autodesk 3dsmax, you can rotate around this outside grey area and the lighter grey as well, the lighter grey is screen space rotation, the other is an axis Im not sure on but its on all the other 3. The example though always shows the correct rotation regardless, theres actually no visible lock there.
We are actually a little hesitant to add operators like + and * for rotators because we think it is rather unclear what they mean or what they do. You would assume that using ‘+’ on two rotators would combine those rotations. Although it will sort of do that, by adding the elements together, this doesn’t work very well with any complicated rotations. That is why we have a ‘Combine Rotators’ function instead.
I find it odd that you make an exception for rotators, Im not understand whats unclear about adding degree’s to degree’s or multiplying degree’s by a float it just seems to me that its exactly the same as vectors. Infact unit vectors and linear colours cause the most confusion I find, atleast linear colour has an explicit definition but it is still often confused with byte colour.
Does the rotator cap out if the summation is greater than 360, is that why because it doesnt actually adhere to the rules of addition?
This is what I was doing, seems to work with floats. I was just curious on the range of rotators.
With something like vector ‘+’ it is clear what that should do - add each element of the vector together. With a rotator ‘+’, it is not so clear - do you want to add each element, or combine rotations in a more consistent way?
I guess Im not understanding what you mean by combine, addition and subtraction have an inherent relationship which goes to the cumulative nature of addition compared to subtraction but they arnt mutually exclusive as adding a negative is treated as addition.
For instance in the above example, I cannot get combine working but the floats work just fine because of my understanding of mathematics.
Do you know who James Golding is Daniel?
Maybe think about his question a bit longer
I think my answer was adequate nathan. Its obvious that combine is causing confusion where its meant to be more clear cut, that I dont understand whats going on with this and I need a clearer explanation.
I know full well who James is and Ive had the pleasure of meeting him on a conference call, I know what he does at Epic as well.
Rotators arnt something documented everywhere on the internet but I do know https://rocket.unrealengine.com/docs/ue4/INT/Editor/UserGuide/LevelEditor/Details/Properties/VectorAndRotator/index.html the range and the type of components that make up these new rotators.
I know floats adhere to the rules of addition so what would happen if I were to multiply out one of the rotators components, like 607 and feed that back into the rotator, will it give me 360? Im going to assume it goes since no ones answered my question but what if I dont want that? Even a microwave timer will allow you to set 120 as 60x2, it doesnt say oh this value is out of my range so maybe 607 does wrap around like the old rotators but Id have to do a range of unit tests when a simple answer would suffice.
The rules of addition are clear and universal is my answer, people can get this information from numerous sources. Making the information domain specific will increase Q/A or unit testing time.
I have alot more questions than I do answers!
As an update on this the reason I couldnt get combine working, or atleast as a guess is that its inputting a vector not a rotator, in that it displays X,Y,Z quite clearly on the combine rotators there.
I used the literal make rotator (structure) so combine rotators received the right type of floats, Pitch, Roll, Yaw.
I can work around this by creating my own macros which allow me to multiply a rotator by a normalized vector, multiple a normalized (unwound) rotator by a vector or unit vector, etc.
Looks very nice!
Have you considered making a BP library of your rotator functions?
That way you can easily share your chosen implementation of blueprint node Rotator functions with the Community!
I’m actually quite eager to see what BP libraries we can all develop to add the the core BP functionality already in place
The issue I had with the libraries was they dont seem to allow me to nest my macros within the standard categories because some are more than 1 category deep. For instance if I use the category Vector it creates a new vector category at the base tree instead of putting my macro under math->vector. Its possible Im missing something but Id like to know how we can adjust the context sensitivity of macros as to match conditions like dragging out from vector etc.
Since Im working on what is going to be a commercial product Im not entirely happy with sharing, I would like to but its whats called a competitive advantage and Id like to keep that for the time being.
You actually separate categories using the | symbol, so you could make the category Math|Rotator for example!
I’ve submitted this for our team to look at. Thanks for noticing.
Awesome, yeah I can work around it by breaking the structure and doing math on the individual components thankfully
The current state of rotators is very painful. A library that at least lets us work around this would be absolutely incredible for blueprints. The state of things as they are is really painful to work with.