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 Studio Chat / [SOLVED] Critical camera rotation bug (attempted value transfers and resets)...

Author
Message
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 30th Oct 2021 23:05
If the user tries to use the only available camera for anything other than a single base camera, it will twitch and spin uncontrollably when the X angle nears +/-90 degrees. The issue surfaces when the user attempts to reset the camera back to an original orientation after using it for another purpose. The quirky camera behavior will occur whether using float values to transfer the camera angles or also a hidden guide object. This renders the only available camera as ultimately useless for anything other than one render point in a scene. It can't be used for render images for shadows, shaders, depth maps, mirrors, cube mapping, or anything else since it can't be reliably set back to its original rotation alignment without this spinning and twitching behavior. Either the float values need to be expanded to support whatever internal precision length the camera's rotations use or a command set like DBPro's 'SetObjectToCameraOrientation', 'SetCameraToObjectOrientation', and 'SetObjectToObjectOrientation' with 1:1 precision needs to be implemented.

I've provided sample code that includes both a float value transfer method as well as trying to use a hidden object that polls the camera's and object's angle values directly. I've also reported the issue on GitHub here: https://github.com/TheGameCreators/AGK-Studio/issues/900 Here is sample code to demonstrate (just let it run for about 5-10 seconds):

The author of this post has marked a post as an answer.

Go to answer

blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 31st Oct 2021 01:29 Edited at: 31st Oct 2021 01:35
it is the nature of 3D rotations apparently. I got around it by calculating the angles independently and applying it to the object/camera.
Or use quaternions
Virtual Nomad
Moderator
18
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 31st Oct 2021 01:35 Edited at: 31st Oct 2021 01:43
gimbal lock? meanwhile, i've tagged the issue @ github.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 31st Oct 2021 01:59
Yes, that is the issue. Internally, it works fine (as it should). But trying to synchronize anything to the camera or the camera out to anything through translation (Angle to Float / Float to Angle) or direct application of values (Angle to Angle) is where things break down. Pre-calculating values for an object or camera is useful, but it needs to work in both directions. So AppGameKit needs a way to retain the internal precision of the rotations through floats and/or commands to prevent any kind of gimbal lock effect to or from objects and the camera.

I did try the quaternion route, but things broke down worse with that method. It's also important that such options be linked to AGK's internal command set and system(s) of rotation for both entity types.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 31st Oct 2021 01:47
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 1st Nov 2021 16:32
You're running into Gimble Lock.
Now a simplistic way around this is to calculate each Rotational Axis...

Why will this resolve Gimble Locking? Simple... because each Rotational Axis shares a Dimension; but how we would calculate each uses Inverse Sin/Cos Calculations.
As such when you hit Cardinal Directions (0.0, 90.0, 180.0, 360.0) well what happens is these calculations cancel each other out and rotation gets "Locked"

So what we do is we calculate said Direction Individually., and Multiple the Results... as such it's best to do it in order.

CalcX
CalcY
CalcZ

XY = X * Y
XYZ = XY * Z

Rotate Object XYZ

Now the easier but more involved method is to use Matrices for this (if you look in the AppGameKit Classic Forum, for my Javid Tutorial conversions... I do this for each Vertex in the Software Renderer; so you can see a working example)
Why AppGameKit only has Vector3 and not a more comprehensive solution (like DBP) for Mathematics is beyond me., I'd imagine most of that code is almost directly portable or they could just use the DirectXMaths Lib (which is Open Source and License, and literally uses no DirectX features, it's just a common maths lib for game development)
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 1st Nov 2021 18:17 Edited at: 1st Nov 2021 18:20
@blink0k - Some related elements, but the issue isn't the behavior of rotations or gimbal lock on its own, it's the lack of transferability. Again, internally, AppGameKit rotations are working correctly for the camera and objects (simply rem out those lines in my sample code above and you'll see the camera pans around 90 degrees on X correctly as it should). You can rotate the camera using the 'RotateCameraLocalXYZ' rotation command set and things stay properly aligned, including compensation for gimbal lock. The core issue I've brought up here and on GitHub is that the same behavior is not transferable to any other entity or value set so that the only available camera can be used for something else. I'll try to restate it a little more clearly.

To use the camera for something like shadows/depth maps, cube mapping, mirrors, or any form of scene/depth capture, you are forced to use the only camera available. That means you have to 'store' the camera's rotation state somehow so that you can restore the camera back to its original location and rotation... and that's where things break down. So there is no way to do this reliably:

- Store current camera (1) location and rotation state
- Place and rotate camera to required location and angle needed to render for secondary scene capture (RenderImage)
- Restore camera back to its original location <- this works fine
- Restore camera back to its original rotation <- this fails when near +/-90 degrees on X, including trying to use either the 'GetCameraAngleXYZ' commands or floats

So either the 'GetCameraAngleXYZ' command set needs to properly import/export the same values used internally when used directly to/from objects and camera or AppGameKit needs a new command set like DBPro had that supports the full precision of those values used internally. Those commands were:

Set Object To Camera Orientation OBJ,CAM
Set Camera To Object Orientation CAM,OBJ
Set Object To Object Orientation OBJFrom,OBJTo
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 1st Nov 2021 23:44


Notice how using your own will work fine... but the actual Get Values seem to have half precision.



SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 2nd Nov 2021 01:11
Yes, the loss of precision seems to be the core of the problem. Plus for trying to use independent floats, as the sample code there shows in the discrepancies between the two sets, you also lose the tie to the Euler/internal angle alignment for other needed operations, breaking an important link to the local rotation options necessary for freeflight/sim style control elements (example, rolling 45 degrees on local Z, then pitching directly down). Ideally, we'd just need the added precision storable in floats or the commands I listed above as solutions.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 2nd Nov 2021 02:52
I don't think it's just the camera. Object rotation yields the same result.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 2nd Nov 2021 03:57
Indeed, the lack of transferability effects everything. The limit of only one camera and its dependency for additional render effects is just the most significant. I'm not sure which route may be more practical to resolve the issue, either retained precision with the GetObjectAngle commands or new commands dedicated to aligning object to the camera, vice versa, and objects to each other. Either solution would solve the issue entirely for me with my projects though.
ando
4
Years of Service
User Offline
Joined: 21st Feb 2020
Location: Australia
Posted: 2nd Nov 2021 21:06
iirc .. y rotation is easy because it is 0 to 360 degrees. Z is 0 to 180 twice, one poitive and one negative. X is 0 to 90 four times. two poitive and two negative. It was a big hastle when I tried to do a 3D radar. I eventually got it to work with quaternians. I thought the problem might go away if we could have 0 to 360 on all 3 axis. The radar demo is here.. https://forum.thegamecreators.com/thread/226510
BASIC appeared in May 1964. Lightning flashed, the wind roared and the Earth moved.
And nine months later I was born.
So here I am.
I am Basic.
Code is in my genes.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 3rd Nov 2021 01:20 Edited at: 3rd Nov 2021 04:05
Nice radar (definitely an admirer and designer of those systems myself I utilize dual 2D and 3D radar systems in my games and it can indeed be a bit tricky to get everything worked out. The quaternion route is generally the only current way to solve certain issues involving rotations. It's too bad precision is lost for those values as well when trying to transfer via floats or the direct 'GetObjectQuatXYZW' command set.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 3rd Nov 2021 16:48
This post has been marked by the post author as the answer.
Well, Ando, I need to extend a thank you to you as well as others in this thread. Your post and others helped remind me of the stability and interoperability of quaternions with eulers across objects and the camera with other calculations I need for my avionics and ship physics systems. Through quite a bit of trial-and-error, I was able to piece together some routines to sort out the problems I kept running into. As far as it relates to just the specific issue in this thread, these three functions provide the simple object-to-camera, camera-to-object, and object-to-object orientation alignments needed to then continue on in other translations and transfers to other angle types and constructs:



From there, I've been able to manage the rest through all secondary calculations and systems I need. So for anyone who might want quick 1:1 object/camera alignments, these commands help set things up just like the DBPro command set. I'll be marking this as solved in GitHub as well. Thanks all!
ando
4
Years of Service
User Offline
Joined: 21st Feb 2020
Location: Australia
Posted: 4th Nov 2021 03:21
Nice ! And I have seen some of your Dark Basic space ship work before. Truly excellent stuff.
BASIC appeared in May 1964. Lightning flashed, the wind roared and the Earth moved.
And nine months later I was born.
So here I am.
I am Basic.
Code is in my genes.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 4th Nov 2021 22:03
Awesome stuff Ando and SFSW... Code pinched

Login to post a reply

Server time is: 2024-04-23 22:21:52
Your offset time is: 2024-04-23 22:21:52