Quarternions, Entity*() Angles and Gimbal Locks

Blitz3D Forums/Blitz3D Programming/Quarternions, Entity*() Angles and Gimbal Locks

_PJ_	(Posted 2009) [#1]

Okay, I've found a few descriptions of this and some mentions of how TurnEntity rather than RotateEntity negates the Gimbal lock etc. where Blitz3D uses Quarternions internally. However, I'm still not very sure about how to go about using this stuff (my maths is terrible too, and quarternions themselves scare me.)

What I am aiming to do, is retrieve a more typical 0 - 360 degree angle for EntityPitch, Yaw and Roll values.

So far I have the following:

Function CorrectVectorPitch#(Pitch#)
	;Return ????????
End Function

Function CorrectVectorYaw#(Yaw#)
	Return (360.0-Yaw#) Mod 360.0
End Function

Function CorrectVectorRoll#(Roll#)
	Return (360.0-(Roll#+180.0) +180.0) Mod 360.0
End Function

I have tried using a combination of Yaw/Roll to find the Pitch, but that didnt seem to work at all.

puki	(Posted 2009) [#2]

This may help:
http://www.dscho.co.uk/blitz/tutorials/quaternions.shtml

puki	(Posted 2009) [#3]

In addition, wouldn't your calc have to be (360.0-(INTERNAL BLITZ FUNCTION(entity)))Mod 360.0

Adam Novagen

(Posted 2009) [#4]

In addition, wouldn't your calc have to be (360.0-(INTERNAL BLITZ FUNCTION(entity)))Mod 360.0

Probably not, as I think he's using his functions like this:

CorrectVectorRoll(EntityRoll(entity))

puki	(Posted 2009) [#5]

I think EntityPitch is an odd one as it doesn't work on the usual 180 basis; it is a 4 x 90 basis - at least that is the way Blitz3D will return it.

_PJ_	(Posted 2009) [#6]

Probably not, as I think he's using his functions like this:

CorrectVectorRoll(EntityRoll(entity))

Precisely that. The reason why I am not passing an entity is so that I can work directly with the degrees, if I may need to use just angles in other calculations. Also, it may even be helpful to change the return to radians to make the functions more arbitrary.

I think EntityPitch is an odd one as it doesn't work on the usual 180 basis; it is a 4 x 90 basis - at least that is the way Blitz3D will return it.

Yep,
It's also a problem because 0 to 90 occurs twice as does -90 to -0 where there's nothing intrinsic to Pitch alone to determione which one is used.
Also why I think the solution to my problem is going to involve working out the relative Pitch according to the combination of Yaw and Roll values.

GIB3D

(Posted 2009) [#7]

Mmk, what seems to be the problem here officer?

InitGraphics()

Global Light = CreateLight()
	
	
Global Camera = CreateCamera()
	PositionEntity Camera,0,0,-5
	
PositionEntity CreateCube(),0,1,1
PositionEntity CreateCube(),0,1,-8
PositionEntity CreateCube(),0,8,0


While Not KeyDown(1)
	
	TurnEntity Camera,0,(KeyDown(203)-KeyDown(205)),0,1
	TurnEntity Camera,(KeyDown(208)-KeyDown(200)),0,0
	
	RotateEntity Camera,EntityPitch(Camera,1),EntityYaw(Camera,1),0,1
	
	UpdateWorld
	RenderWorld
	
	Text 0,0,"Pitch " + EntityPitch(Camera,1)
	Text 0,20,"Yaw " + EntityYaw(Camera,1)
	Text 0,40,"Roll " + EntityRoll(Camera,1)
	
	Flip
	
Wend
End

Function InitGraphics(w = 1024, h = 768,title$="Blitz3D Program",exit_message$="")
	Graphics3D w, h, 32, 2
	SetBuffer BackBuffer()
	SeedRnd MilliSecs()
	
	If exit_message <> ""
		AppTitle title,exit_message
			Else
				AppTitle title
	EndIf
End Function

Stevie G

(Posted 2009) [#8]

@ Malice, why do you need 0-360 values for the rotations? Can you explain in more detail?

_PJ_	(Posted 2009) [#9]

Mmk, what seems to be the problem here officer?

The problem is, that I am trying to obtain 0-360 degree angles for the rotational vectors passed into the functions.
Your code doesn't address the values at all, nor take any input aside from specific integral keypresses.

Malice, why do you need 0-360 values for the rotations? Can you explain in more detail?

For calculations for 3D 'flight' movement were "thrust" vectors apply across each dimension.
By maintaining a consistent scale throughout it is easier to corelate these angles to global angles used elsewhere.

Yasha

(Posted 2009) [#10]

EntityPitch probably returns values only up to 90 because otherwise there would be ambiguity; if you pitched up "over the top" to say 135, you'd still have yaw and roll of 0, which makes no sense because you're upside down and pointing backwards. By defining the pitch at that orientation as only 45, you can get intuitive values for the yaw and roll that actually reflect the state of affairs. I presume Mark chose to have pitch be the odd one out as games are more likely to take place with movement primarily in X/Z and some aiming up and down, and such movement would be impossible without a yaw value that goes all the way around.

Graphics3D 640,480,32,6

piv=CreatePivot()

RotateEntity piv,135,0,0

Print EntityPitch(piv)
Print EntityYaw(piv)
Print EntityRoll(piv)

WaitKey
End

The effect of this is that pitch only has a 180 degree range, which is probably why trying to get values between 0 and 360 is not working too well.

_PJ_	(Posted 2009) [#11]

In the same way, though, It should be possible, to define Pitch in terms of Yaw and Roll, shouldn't it?

Ideally if only using two angle vectors, the precise description of an entities rotation in360 degrees per direction could be obtained without ambiguity.

As pitch would introduce the ambiguities, and considering its locality to the default "facing" of an entity, if it were Rotated to Pitch Yaw AND Roll values, it would be turned around through Yaw and Roll, but then turned again with the Pitch vector.

Hopefully by only using two vectors, a full and accurate description can be obtained which can be used to represent the facing separately in global space.