@craggy sparrow go on...
#wytea offsets
trim junco
craggy sparrow
is that clearer, or should I try to explain the problem again?
trim junco
lots of VR games always use the same direction for north, no matter where you start.
at least they did when I owned a VR system.
but let's try to get you what you want.
craggy sparrow
thing is, I want the player to start in the same direction in game, regardless of where they're facing irl at the start
dawn creek
its defining an offset rotation that is equal to the unity-camera's initial rotation rotated by the inverse of the gyros rotation. In Update, it applies that offset. If the gyro's rotation is equal to the initial gyro rotation, the inverse and forward GyroToUnity bit will cancel out and you'll just get the initial unity-camera rotation.
It is essentially just defining the initial gyro rotation as the zero point for your rotations.
trim junco
so when the player starts they have their IRL heading and you want the in-game heading to be north and the two to stay synced after that.
craggy sparrow
so when the player starts they have their IRL heading and you want the in-game h...
yes. so the camera just responds to the gyro's movements after that, not exactly the direction
trim junco
and you probably want to ignore the tilt, only adjust the pan?
craggy sparrow
and you probably want to ignore the tilt, only adjust the pan?
that's not quite important
I think I need to draw things out to properly picture it
trim junco
that's a good idea!
dawn creek
another way of framing the initial question is "how do I make it so my game interprets the initial gyro rotation as Quaternion.identity?"
and the answer is to multiply the gyro rotation by the inverse of its initial rotation
trim junco
@dawn creek is correct
like, in-game initial orientation is A. IRL orientation is B. the difference C = B-A. every update you take adjustedView = IRL - C
conveniently A is identity, so C=B on the first frame.
craggy sparrow
OH
trim junco
but if you leave it as C=B-A then if you change the starting orientation the rest of the math s
should still work
craggy sparrow
I think that's starting to clear things up a bit for me, but I'll continue drawing out a diagram first to make sure I really got it
craggy sparrow
okay there wasn't as much diagraming as I thought, but it helped
this looks and sounds about right
dawn creek
yep, that's the idea
also, diagramming quaternions as circles is a good idea. I wasn't sure how you were going to visualize it
craggy sparrow
I was actually hoping it could clear up a follow up question of mine, but i dont see how it's quite related. I'll elaborate on that in a sec
https://hatebin.com/jahuzjkkbr
This is my full script, and before I added the offset logic, there was this line
camContainer.transform.rotation = Quaternion.Euler(90f, 90f, 0f);
that seemed necessary to orientate my camera correctly in a portrait mode
but after I added the Inverse quaternion logic to cater for the real world offsetting thing, it didn't seem necessary anymore?
For example, without that line, it was this
I added it so it'd look like this
but after adding the inverse quaternion logic, it seems to break it. So i was wondering what about multiplying by the inverse might've made that camera container rotation code not necessary?
i can rephrase if necessary
dawn creek
what did your code look like before doing the offset thing?
void Update()
{
tranform.localRotation = GyroToUnity(Gyro.attitude);
}
?
craggy sparrow
what did your code look like before doing the offset thing?
```cs
void Update()
...
oh, yes
dawn creek
that code is completely ignoring the camera rotation you set in the editor
the offset is capturing what you set
so the rotation is baked into the offset
if you had instead done
transform.localRotation = intialLocalRotation * GyroToUnity(Gyro.attitude);
I think you wouldn't have needed the container rotation either
craggy sparrow
i dont think I follow..
I found out that if I did
offset = transform.localRotation * Quaternion.Inverse(GyroToUnity(Input.gyro.attitude));
transform.localRotation = offset * GyroToUnity(Gyro.attitude);
then I dont need to do the giving the camera a parent and rotating the parent part
but I don't understand why
dawn creek
private Quaternion initialRotation;
private void Start()
{
initialRotation = transform.localRotation; // captures whatever rotation you applied to the camera in the editor
}
private void Update()
{
transform.localRotation = intialRotation * GryoToUnity(Gyro.attitude); // takes the rotation you applied in the editor and rotates it based on gyro
}
if you don't capture the rotation you set, you're just directly applying whatever orientation the gyro happens to have natively
which is landscape, apparently
the (new) offset does two different things. it counteracts the gyros initial orientation AND it applies your initial orientation.
the old code didn't do either of those things
so it just used the raw gyro orientation
without your initial orientation used at all
dawn creek
hmmm...
craggy sparrow
For example, without that line, it was this
identical to this one
craggy sparrow
thank you for the time regardless. @trim junco too