Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / 1.#QNAN0 when rotating a sphere

Author
Message
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 02:33
When I rotate a sphere in its X plane and the angle of the sphere goes above 89.9999 ie becomes 90, the sphere returns that its angle is 1.#QNAN0, this causes my screen to blank to the background colour momentarily at that value. When it becomes -90 it does the same.

From this thread http://forum.thegamecreators.com/?m=forum_view&t=204138&b=22 I see that this error code means it is a `quiet fail` in c++ as the computation is making a non real number.

Is this an issue with AppGameKit? Or is it my local object rotations in non wrapped values?? I have tried an AppGameKit sphere and an .OBJ sphere, but the glitch still persists.

My camera is placed at the sphere center and then is moved back and positioned to viewing distance before the update/swap routine, and shares the object X angle. When I press a key the sphere is rotated by 0.01 each frame.
I just checked the camera angle and it also reports itself wrongly as -1.#IND00 instead of 90???

It was the same in v108x and I am now on Alpha 3
Using Windows 8.1
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 03:51 Edited at: 25th Jun 2014 05:16
Made some code to illustrate this:-



I set the object to 90 on the X axis and it comes out at a wrong value to begin with! If you carefully get to exactly 90 degrees the screen blanks and shows the two floats returning incorrect values.

Is it just like this on Windows 8.1 or a developmental glitch?
Lucas Tiridath
AGK Developer
16
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 25th Jun 2014 11:02
Sounds like an AppGameKit bug. I can reproduce the same issue on Windows 7 x64 SP1. It's probably the result of the direction vector of the object at x=90 being the same as the up vector. If you notice, the same thing doesn't happen at y=90 or z=90.

SoftMotion3D
AGK Developer
19
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 25th Jun 2014 13:29
oh I get the exact same error. My solution is just to not rotate on the x axis more then 80 deg + or - each way. Then the glitch stays away.

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 17:04
Thanks for the confirms, I feel glad it helped, and my badge appeared too

@softmotion- my program needs free rotations of xyz, and I think alot of other peoples will need this bug squashing too. As a developer(s) can you put a good word in to the team and get it in quarantine for the next Alpha?

@Lucas-thanks for the Win7 confirm, I have Win7 64 and Win8.1 64, just hadn`t got round to transferring it to test there. Yes it must be something in the global versus local rotation maths cos as you say it only does it at exactly 90 degrees. Maybe its just that it needs <= in its computation as it`s behaving like its just <

Anyway lets hope it gets fixed, I can live with it for now my screen just flashes blue very occasionally but its good to know it`s not my AppGameKit programming causing it

SoftMotion3D
AGK Developer
19
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 25th Jun 2014 18:10
hehe... my title may be misinterpreted a tad.

I develop using agk... im not one of the guys developing it. Love using it however

29 games
19
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 25th Jun 2014 18:42
Hi, I've not seen this error but I have had problems with rotation values that are either +90 -90 and +270 -270 when returning the values of rotation.

I've not had any issue "going through" these angles (ie going from 0 and rotation through a full circle the object on the screen is rotated correctly). For angles either side, say 90.2 or 88.8, AppGameKit should return the correct values.

For my animation project I had to create a function that detects the offending angles and just minuses 0.2 of a degree.

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 19:00
@softmotion-Oh I understand thanks, hey your Softmotion site gets flagged as a suspicious link by my security, I was checking out your Qmidi when it gets locked down and redirected, always makes me wonder if it to be a true report when that happens??? Security bug?

Yes, likewise, AGKv2 is shaping up to be awesome to use.

Like to see it do AA with bump/detail/specular/diffuse/glow simultaneous shader(it may take me a while to figure that shader..lol)....then it will just pure ROCK! That and this 1.QNAN0 error mending of course

Hopefull

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 25th Jun 2014 19:08
I have only had a little time to look at your code but have some ideas.

You must be careful when using local rotations and then retrieving the rotations back through the getobjectangle() command. Applying what is returned to the camera will highlight the issue, as you have discovered.

Just for a quick test, try rotating the camera locally too by the same amount, this should be safe. Also, try retrieving the rotation as a quaternion and then applying that to the camera, this may fix the issue.

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 19:10
@29games-yeah i tried overriding the x plane but it messed with the follow through of the angle and thinking about it, it would limit a players accuracy rather terminally if you couldn`t aim down the 90 angle....I think rather hope for a rebuild of what admittedly is an AlphaV3 as it is such a single character mistake programatically speaking on the C++ side. It makes me wonder if this would be cureable in tier2, this is a tier1 investigation...idk....really must learn that...lol
SoftMotion3D
AGK Developer
19
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 25th Jun 2014 19:11
yeah its not a security bug... its just the host provider that im using does not have an up to date security certificate.

I will be changing sites next year most likely

Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 25th Jun 2014 19:21
Just had a look at this and I can confirm there is a bug with certain angles in AGK. Part of the problem is floating point inaccuracies around X=90 that mean even if I fix it it will jump to 90 where it currently jumps to 1.#QNAN I might be able to switch to an alternative method in these case for more accuracy, but then there's an issue with how to transition between methods smoothly. I'll see what I can do.

Also since AppGameKit uses quaternions internally, if you want to match angles exactly do this instead
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 25th Jun 2014 19:43
@Paul - Could it be that tan(90) = error?

I addressed this issue in the past(direct x etc) by not allowing a value of 90, test for it and change it to 89.99 or 90.01.

The real solution is to use quaternions though as you have stated.

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 25th Jun 2014 22:33
@Paul Johnston -no, the object quat line cures my test program only when you first meet the 90th degree. Then you notice the floats stick on 90 while the quat value still increases. Then when the floats move again if you revisit the 90th degree you`ll find the error has returned unabated.

I had seen quaternion commands but had yet to learn about them so was just using simple rotate commands. Can someone tell me what they are or give a simple rotation program based on them? What for example is `w` the fourth vector???

I see euler rotation is also supported, that`s four ways to think of a simple rotation. Ok I know that matrixised rotations are far from simple and all that...but global/local/quaternion or euler sounds problematic.

In dbPro I had ezrotate so there it was euler rotations which I forgave for the simpler rotate xyz commands, but never noticed an error. Well perhaps it was the cause for things misreporting their positions when the camera got too far away from 0,0,0 but I`ll never know as dbpro no longer works in my Win8.1 environment. But could a working quaternion representation be made to multiply or even wrap(360) to the rotate command? A wrap var command would be handy here for these kinds of maths from an AppGameKit perspective? Complex topic it seems, rotation and transformation.

So like this below there is still a misplacing of the initial rotate object 90 call but 1st visit to 90 it seems to work and reports 90, then when you move the floats away and return a second time to 90 degrees the error has returned, plus the quat increases but the rotation does not momentarily. The euler commands arent funtional yet so rem`ed out and I don`t know how to translate a quat to a 360 rotation yet:-



Working quat rotation examples greatly appreciated

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 25th Jun 2014 23:15 Edited at: 25th Jun 2014 23:15
You have fixed the problem since the sphere no longer disappears, so Paul was correct.

I would not worry too much about the returned euler values, unless you need them for something else.

AGK should really have its own math library for dealing with quaternions like dbpro has for matrices, it already has it internally and for tier 2. I'm surprised no one has posted a tier 1 quaternion library yet, if they had then rotations would become much easier.

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 26th Jun 2014 01:31 Edited at: 26th Jun 2014 01:36
Ah yes indeed my main code no longer glitches at that angle if I ask the camera to match the Quat of the sphere, thanks Paul Johnston

It`s that it still reports the error in the floats and thinks 90 degrees is 89.980209. The sticky object angle leave me wondering if when I move an object along that angle it may not arrive where it should be over time were there to be no 1.QNAN0 error: agreed not too much of a problem.

Also it may cause rotating objects to drift position which I had been wondering about too, but that may be the peculiarities of other parts of what I`m coding and perhaps not as a result of this tiny bug....idk yet

But yes functionally its much better than disappearing objects, so big thanks for the work around Paul (and Matty), I got fixated with the floats there and it is after-all just the reference sphere
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 26th Jun 2014 03:15
I still get the occasional misdrawn odd frame glitch which still has me puzzled as nothing is moving on the x axis but my view sphere and similarly quat`ed object attached to that sphere. I only have 5 main objects in the scene which has a long rotation cycle, so if I discover why I`ll post back. It may be that the x axis isn`t always the only axis that it occurs on...idk yet.
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 26th Jun 2014 05:45
I think I've worked out a solution, near x=90 it will gradually transition to a different method that can handle the specific case of x=90 more accurately. When I release the next version let me know if you still have trouble.

Quote: "Could it be that tan(90) = error?"


The problem is due to gimbal lock, when X is near 90 or -90 the Y and Z axis line up and the math used to separate out the Euler angles breaks down. In the case of 1.#QNAN0 a value passed to ASin crept above 1.0, and floating point inaccuracies in general mean any X angles above 89.9 become indistinguishable. The best solution seems to be to assume Z=0 at this point, since it is lined up with Y then it no longer serves any purpose, and the math gets simple enough that X can be calculated again. That or don't exceed X>89 and X<-89 to be on the safe side!

Quote: "I had seen quaternion commands but had yet to learn about them so was just using simple rotate commands. Can someone tell me what they are"


I don't fully understand the math myself, and I wouldn't recommend trying to unless you really like complex numbers, but you can use the analogy of representing a point on the 2D surface of the earth. We can use longitude and latitude (only 2 values) which work well except for at the poles, where one of them becomes redundant, a bit like gimbal lock in Euler. Now imagine representing a point on the earth by using a 3D vector pointing out from the center of the earth to a point on the surface, this can be represented with 3 values (X,Y,Z) and doesn't suffer from any problems at the poles.

Interpolating between two of these vectors would allow us to easily find the shortest path between two points, whereas trying to do the same thing with longitude and latitude is much more complicated.

In the same way, quaternions are a 4D vector pointing to the surface of a 4D sphere which represents a rotation in 3D space, whilst Euler angles are like the longitude and latitude from before. They are just both different ways of representing a rotation, but because quaternions are vectors we can use them to easily interpolate between two rotations which makes animation much easier.

Word of warning, if you do start playing with quaternions and interpolating them, make sure you normalise them afterwards (so w^2 + x^2 + y^2 + z^2 = 1), otherwise like interpolating 3D vectors on the surface of the earth an interpolated vector will be shorter that the two original vectors, no longer pointing to a point on the surface of the earth but somewhere inside it. Similarly quaternions that aren't length 1 no longer point to a 3D rotation but some kind of skew or distortion.
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 26th Jun 2014 12:23
You don't need to understand the underlying math to use quaternions. People(including me) get themselves into all kinds of trouble using euler angles in game development, quaternions are a life saver in some situations.

I would advise anyone to try to learn to use them, although it's hard in tier 1 because you would need to code all the quat operations yourself, they are available on the web of course, if anyone does that then please post it

Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 26th Jun 2014 17:48
@Paul Johnston- Thanks Paul, lets hope you`ve got it sorted then, I look forward to the next release eagerly.

Having read the Quaternions Wiki and understood the history and origin of them as it were I now have a wider understanding of them. Like in a map game the calculation for the distance between any two points on the map is the difference between the sum of the squares, it is like this that William Hamilton is using to calculate a position but he ads a 4th dimension to the flat map equation, ie a radius, in our case from the origin of the model, and includes it in the sum of its squares. As a flat map would not accurately describe the rotated vertex point alone without the radius from its origin and the angle of our rotation.

I think quats are more for transforming vertex positions in an object matrix, but perhaps this is what is occurring when I ask AppGameKit to rotate an object, ie it is transforming the objects vertex matrix with Hamiltons equation. Whilst messing around with them I found my sphere was becoming oblate and stretching flat....

So to calculate a degree from the equation would it be true to say that (x*x)*360=anglex*anglex as our w is unified per vertex and so irrelevant to us in this scenario as we are not counting through each of our objects vertex positions? This is just thinking aloud, please correct me if I am wrong.

Matty seems to think that this should be precalculated in a library, you know that sounds like sense as rotations need to be accurate and are the basis for any game.

But essentially there are no units called QUATERNIONS, just equations of vertex positions...lol, unlike degrees

http://en.wikipedia.org/wiki/Quaternion
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 26th Jun 2014 18:19
Quote: "would it be true to say that (x*x)*360=anglex*anglex"


Unfortunately there is no direct relation between the quaternion X and the Euler angX. If the object is only rotated in the angX direction, so angY=0 and angZ=0 then the relation is W=Cos(angX) and X=Sin(angX) Y=0 and Z=0 but introducing any angY or angZ rotation introduces other terms into W and X, and Y and Z are no longer 0.

Quaternions are useful when combining rotations (in that sense they are similar to rotation matrices but only take 4 values instead of 9), and they are the only format that can be easily interpolated. But when transforming many vertices by the same rotation then rotation matrices are actually faster, so in that case the quaternion can be converted to a matrix which is then applied to the vertices. In AppGameKit the object's rotation is represented with a quaternion and any rotation commands like RotateObjectLocalX() are converted to a quaternion and then "added" to the object's quaternion. Then when we want to draw the object the quaternion is converted into a matrix so we can transform the vertices quickly. Hence the problem when we want to know the object's Euler X angle, since the quaternion must be deconstructed to work out what Euler angles went into it, which at X=90 has many solutions.

When I move on to the 3D work fully (After the compiler/IDE work) I'll look at adding some more quaternion commands so they can be manipulated more easily.

Quote: "Whilst messing around with them I found my sphere was becoming oblate and stretching flat...."


This happens if w^2 + x^2 + y^2 + z^2 is no longer equal to 1, normalising like you would a 3D vector should correct it.
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 26th Jun 2014 20:10
Ok, I see so its trigonometry starting from the origin of our object x0,y0,z0 we move by w and find x1,y1,z1 that then rotated at angle A becomes our first distance calculation to a second moved point in space x2,y2,z2 which is 90 degrees from our first point . Then we trig again to find the actual x3,y3,z3 of our third point in space that is the real position of our rotated point on a circle of the same orginal radius w from the centre of the object.

So any quaternion rotation is the intersection point of three radii of changing center, 1st at object origin, 2nd is at x,y,z, 3rd is distance moved at angle a that points to our real end position or 4th point essentially.

This is vertex translation I think.
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 26th Jun 2014 21:46
Would it not be quicker to go from object origins x0 using Pi we know the circumference of x1 at w radius or Pi*w^2 and simply find the x4 along this (circumference/360)*A at angle moved A.

: so tan A=Opposite/w which says our correct distance moved is the Opposite or Opposite=tan A/w because w doesn`t change from the start and end position.

Is this what Matty is hinting at?
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 27th Jun 2014 00:34
Quote: "So any quaternion rotation is the intersection point of three radii of changing center"


I don't know, that's beyond my level of understanding, I only read up on the equations used to transform between quaternions, Euler angles, and rotation matrices. You might find this page interesting http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
Weave
AGK Bronze Backer
18
Years of Service
User Offline
Joined: 26th Sep 2006
Location:
Posted: 27th Jun 2014 03:25
Thanks Paul it has helped in an understanding of at least thinking what they are from a more simplified Geometric perspective.

Login to post a reply

Server time is: 2024-11-25 06:59:17
Your offset time is: 2024-11-25 06:59:17