scippie

Member

83

119 Neutral

• Rank
Member

• Interests
Audio
Design
Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

1. Spaceship controls -> autopilot

I am currently looking into a non-mathematical way to solve this problem as it does not really seem to be something that can be solved straightforward.
2. Spaceship controls -> autopilot

The thrust in my implementation is fine, it's controlling it on auto-pilot that is the problem.

Thanks!
4. Spaceship controls -> autopilot

Ok, you are right, I have really been expressing myself completely incorrectly. Of course, quaternions and matrices are the same for rotation and can both prevent gimbal lock. What I really meant to say was working with yaw, pitch and roll with a constant reference is different and will also cause gimbal lock. But, I really do understand it, no worries 🙂
5. Spaceship controls -> autopilot

Cool! Yes please, share your code! 😉
6. Spaceship controls -> autopilot

I was going to explain why I don't agree (because of the way the planes already change when you adjust one thruster even before you have calculated the new rotation), but you are making me think now... let me think about this 🙂
7. Spaceship controls -> autopilot

Well, that's exactly what I was doing now and that is exactly my problem: calculating the thrust so that all trajectories end up at (0, 0, 0) at the same time. By changing the pitch of the ship, the yaw is already no longer valid as it will make your ship roll because of the normalized way quaternions work. Your XY/XZ plane as you put it, constantly changes. Edit: and as you need to calculate all thrusting forces at a time before you apply them to the calculations that actually changes the ship rotation, they are immediately badly chosen. This is not a completely different approach. I did it based on what you said above: looking at what my angles are now and where they need to be and just 'virtually pressing keys' until I get there. But calculating exactly when and how much to apply is what I am unable to do and the result is that the ship oversteers, so starts applying counter forces, oversteers again in the other direction, starts applying counter forces, etc... It will come to the end point most of the time after shaking back and fro several times but sometimes, the oversteering is so much that it starts rotating in circles and never gets there. Steering too little will look silly, steering too much will make it go past the target. Calculating that exact number is what I am actually trying to ask. The suggested PID controller does this by trial and error, which is fine, but there also, it is a fine tuning of constant values which might be good in most situations but can generate untested situations where the ship will start spinning and never find its target, because... in the end, it comes to: well... we need to go there, let's just give some thrust and see what happens... while a human being will 'feel' where to go and will already start thrusting more aimed.
8. Spaceship controls -> autopilot

What I mean is that quaternions don't work in the yaw/pitch/roll sense. I know you can construct a quaternion from them, but then you could as well be using matrices and have gimbal lock problems. What I mean is that if it were, I wouldn't be asking this question as I would just make sure the yaw and the pitch would linearly move to the target. But if you do this with quaternions, you are automatically influencing the other parts of the rotation. If you pitch, your yaw-axis is already changed and no longer has a reference to the original 3D axis. I had already searched this forum (and others) extensively and had already found these discussions. I had found the PID approach and it was new to me and I know how they work and I might end up using it, but it is an inaccurate system which can easily lead to unforseen/untested bugs where your ship starts spinning because of its 'just try and then correct'-approach. Maybe I should have mentioned that in my OP. Edit: also, the PID uses a fixed time-step between frames. I prefer to find a solution that works on fluctuating time steps. I would really think that there should be a more mathematical, more robust solution. Thank you, but it is so much easier in 2D. You just take a rotation and thrust to it (and I have done that one before). The problem is that by using quaternions, you no longer simply change one rotation, you automatically change them all, making the difference between your current state and the target change more than just in one angle. In 2D, you don't have that problem.
9. Spaceship controls -> autopilot

I am creating a simple spaceship sim with 6DOF flying. For the ships' angle, I use a quaternion and with the keyboard, I can change yaw, pitch and roll separately which result in three quaternions which are multiplied into the current rotation. The rotation force is limited by a value [-1.0 ... 1.0] and is built up gradually, not only to simulate joystick controls on the keyboard, but also because it feels realistic that the thrusters must build up their power. Then, I also have a throttle [0.0 ... 1.0] which makes the ship move in the direction of the rotation. Now, I am trying to create an autopilot and the first thing I need is auto-aim. When I am looking at a planet in front of me and I want the autopilot to move to the planet behind me, I need it to handle the rotation and the thruster to get there. Simply doing quaternion interpolation (slerp) is not acceptable as this does not allow me to limit the thrust-force (or in other words, I would not be able to know how much my thrusters would be burning). Also, this would not take the building up of the power for the thrusters. I have tried just coding it as it feels, taking the polar directions of where I am looking at and the polar direction of where I am going to and just adjust yaw and pitch thrusters to rotate there, but as you know, rotation with quaternions isn't as linear as I would hope and the result is constantly reviewed which not only makes it look unnatural but also makes it do spirally smaller getting circles around the target because of the thruster-forces which I don't really know how to calculate accurately because of the same reason. Can anyone give me some tips and/or point me to a solution? The math currently is like this: yaw_thruster, pitch_thruster, roll_thruster are values between [-1 ... 1] and are added with a factor in function of passed time. rot_x_axis, rot_y_axis, rot_z_axis are axis-angle quaternions with the thruster values * passed time as angle. They are all multiplied with the ship rotation on every frame and I normalize the ship rotation from time to time to handle precision errors. I calculate polar direction vectors by calculating the (normalized) z-axis from the rotation and then: theta = atan2(z.x, -z.z), phi = acos(z.y). These things all seem to work perfectly.
10. Can't get stencil buffer to work

Yes, I know. But when everything fails, you begin to doubt what you know. Actually, my engine only needs the depth_stencil buffer in framebuffers, not in the main backbuffer, so I will disable it there.
11. Can't get stencil buffer to work

I found out what the problem was: I made the false assumption that when attaching a DEPTH24_STENCIL8 buffer to GL_DEPTH_ATTACHMENT to a framebuffer would be enough to make it also have a stencil buffer. But when I queried for GL_STENCIL_BITS, I found out that I had 0 stencil bits. So, you also need to attach the same buffer as GL_STENCIL_ATTACHMENT. Problem solved!
12. Geometry shader can't output more than 2 components

I'd love to post my solution on this problem, but I was still unable to make it work. Sorry for the bump, but is there really no one who can help me with this?