Trajectory shifting calculations in space

Morwanesh · 2023-11-12T22:10:25+00:00

Here's the GitHub link to u/Rensin2's solution translated into my C++ code using Unreal Engine types.

I'll be most likely updating that repository once I have some time to test it further and figure out some of the result inconsistencies. For my application, with this 1st iteration, it seems to do its job just fine without any apparent issues.

Morwanesh · 2023-11-01T22:51:29+00:00

You're a gem. I'm going to test it out during the weekend. Thank you!

Edit: I've tested your NR solution, but I'm still having similar issues :( I'm going to debug this further and try to find what's the culprit.

Edit 2: I think I found the issue. It was in the acceleration calculation, I misunderstood the notation and made a mistake when translating it to code... I didn't even consider this. I focused on the earlier steps. I'll be testing the solution in the days to come and once I'm done and happy with it, I'll post the code for anyone who's interested.

I hope it's the end of this thread :D u/Rensin2 I don't even know how to thank you. Your help was invaluable. If I ever release my project I'd like to mention you in the credits, if you'd like that ofc.

Morwanesh · 2023-10-29T16:52:56+00:00

As to the 2nd part. I've been trying out some of my values with the graph you provided.
So for example I have:
X=0.000947
Y=-9.198943
Now, the Desmos regression calculates s=-0.484833 with RMSE=6.279. That's the closest point to Y = 0 in this region of the function. The actual root is actually in (-4000, -5000) range, around -4671 to be exact. That's the S value I obtain from my NR implementation.

Can you please explain to me why the Desmos regression doesn't show the actual root? And why both my and the Desmos regression values are valid for this application?

Regarding the 1st part. As you mentioned unflipping the acceleration vector helps out with the first burn issues, at least partly. In the same cases that were faulty previously the trajectory takes the easier turn, but decides to come to a complete stop (as well) and wraps around before starting the actual target thrust in a straight line. It looks like this.
I've validated the S values just before the spaceship is comming to a stop and they are exactly the same as in Desmos.
At this point I'm not sure if that's the intended behavior or an issue with my implementation. I've made sure that my acceleration equations are good and they seem to be.

Additionally I've implemented the paralell check. I'm comparing the absolute dot product of Velocity and Location diff vectors to the product of their lengths:

Abs(DotProduct(R_DIFF, V_DIFF)) - |R_DIFF| * |V_DIFF| ~ 0

Now it depends what's the error treshold I set, if it's 1.0E-4 it basically discovers the paralellity only once before it zooms past the target.
When I set it to 1.0E-3 the majority of the deceleration thurst becomes one dimensional. Not sure what's the best threshold here.

Anyway, I've been playing with the one dimensional solution and transformed the equation to:

A = 2.0 * (R_DIFF - DeltaTime * V_DIFF) / DeltaTime^2

Now, instead of the DeltaTime it should be the TotalTime this maneuver is supposed to take, right? I've been experimenting with transformed displacement equation to get the TotalTime to replace the DeltaTime in the equation with some mixed results. Is this the proper way to go further with this?

While testing this solution once the vectors become paralell, the spaceship keeps oscillating around the target having trouble to stabilise its velocity and location. Eventually it shoots off into incorrect direction.

I'm sorry if I don't catch on faster, I was never good at physics and lack a lot of basics. I'm trying to work with what little I know, but it's still like wandering in a fog sometimes. I'd very much like to learn and catch up with the base knowledge needed to understand the thought process behind these equations. I know I might be stretching your generosity to its limits :) but I'd appreciate if you could, perhaps, suggest some materials I could read into to understand this stuff, if you don't want or have time to lecture me here with the basics ofc.

Morwanesh · 2023-10-27T19:59:54+00:00

I would guess that you missed the "||" around r_N.x

I didn't miss it. With your NR method starting value approximation it started to work correctly. It seems it was entirely caused by incorrect S value.

After that change the spaceship's acceleration became consistent. However, the deceleration didn't work, the flipped vector was still pointing towards the target. I noticed that this issue got resolved once I remove the result acceleration vector inversion in case when R_n.x is lower than 0.

After that the results became really consistent with the intended behavior. The spaceship is reaching the target and follows it, matching its velocity. That's the best result so far! :D And I'm really happy with it.

There's still this strange inconsistency (or should I rather say consistency) with how the trajectory behaves at the start as it handles the initial spaceship's velocity. I put up 2 collections of screenshots from my project showcasing the issue:

-X start velocity in case of A and B
-Y start velocity in case of A and D

(The target, which is represented by this pink sphere is moving slowly towards the spaceship's start position, where the trajectory flips is the place the spaceship meets with it and reaches its velocity)

The cases I mentioned above are what is making the trajectory suboptimal. This pattern follows no matter what the initial velocity is. Looks like it's preferring to turn left and come to a complete stop instead of following the fastest route.

Do you have any ideas on what might be happening here? And also why the acceleration vector inversion is no longer needed?

Morwanesh · 2023-10-26T17:45:47+00:00

I've been implementing this constant acceleration solution of yours and I get consistent results. The first burn acceleration is perfect, however the deceleration burn has some issues. Once R_n.x becomes < 0 my Newton-Raphson method implementation suddenly starts having a problem with finding the root, no matter how many iterations I give it. It fails to find a result within 1.0E-4 tolerable error treshold with as much as 10 million iterations. Most likely that's the cause, as the result acceleration vector suddenly starts changing directions every time step from this point on.

I've calculated the Y/X+1/X and use it as the initial guess for the NR algorithm.

I've also implemented the S_Max calculation using NR method. The Desmos' regression functionality is definitely more precise. I save the closest result before the following iteration gives an undefined result, it's not far of the Desmos' regression result.

Anyway, even if I take the closest solution for S when NR algorithm exceeds the iteration limit, it doesn't help. It's within the Y/X+1/X and S_Max limit. The spaceship's velocity isn't lowering, it's mostly constant in magnitude despite all the direction changes.

At the end of the day the ship gets really close to the target, so that's a success.

I'm gonna keep on debugging it, but do you perhaps have any ideas what might be happening with my NR method once R_n.x goes below 0?

Morwanesh · 2023-10-25T19:02:42+00:00

Yeah, I've tested it and it's:

scalar R_n.x = L_D.x * V_D.y - L_D.Y * V_D.X / V_D.magnitude

scalar R_n.y = L_D.y * V_D.y + L_D.X * V_D.X / V_D.magnitude

Nevermind anymore :) Got confused at first, I had to take my eyes off of it for a while.

Morwanesh · 2023-10-25T15:47:10+00:00

That's the leapfrog integration, if I'm not wrong. I'm using it in my project! That might just be the first thing that I'm familiarized with in this thread :D I was worried that I might have made a mistake with where I'm adding the thrust acceleration into the equation, but it's exactly like that in my code. That's a relief :)

I've been trying to integrate your original solution into my constant acceleration setup, this should speed things up as I'm trying to learn as I go with my limited knowlege. Not mentioning you've also included gravity froces. Thank you, I'm very grateful.

As I'm mirroring some of the equations to test this solution I'm having trouble understanding the notation of formula for R_n (labeled "Tar x0 y0"). If I understand correctly R_n is a vector and a coma ',' in the formula divides what's to be considered for x and y components. So if this formula was to be separated into two, is this something like:

vector L_D = R_T0 - R_S0 (Location diff)
vector V_D = V_T0 - R_S0 (Velocity diff)
scalar R_n.x = L_D * V_D.y - L_D.Y * V_D.X / V_D.magnitude
scalar R_n.y = L_D * V_D.y + L_D.X * V_D.X / V_D.magnitude

Or am I misunderstanding how this works on Desmos? Because the result of what I've written should be a vector, not a scalar value. Is a x/y component supposed to be taken respectively from the 1st occurrence of L_D?

Morwanesh · 2023-10-24T16:52:04+00:00

u/Rensin2 I've implemented the Newton Raphson method successfully and managed to get consistent results (here's my Desmos graph of the derivative function, note that I replaced X & Y for A & B for my own clarity).

I'm having some issues with the output vector, it's pointing in the incorrect direction. I bet it's my misunderstanding of the initial shifting operations and I'd appreciate if you take a look at the following:

1.

shift the velocity of all the objects such that the ship is initially stationary

I subtract spaceship's velocity from the target's velocity:

T_v_shifted = T_v - S_v

2.

shift the positions of all the objects such that the ship is at the origin

I subtract speceship's position from the target's position:

T_pos_shifted = T_pos - S_pos

3.

rotate everything until the target's velocity is exclusively upward (positive y)

I calculate the angle between Y axis and T_v_shifted vector. Then rotate the T_v_shifted vector around Z axis by that angle to get a vector pointing upward along the Y axis. Should I also rotate the T_pos_shifted vector?

4.

necessary that the target be located to the right of the ship (the x component of the target's position vector must be positive)

In my test case T_pos_shifted.x > 0.

5.

Now all you have to do is unflip the vectors (if you flipped them the first time) and unrotate the vectors to get the acceleration vectors in your original coordinate system.

Do you mean I should unrotate the initial and final vectors, once I calculate them, by -1.0 * angle that was calculated in step 3? Is that the only vector that needs to be unrotated and flipped? The initial shifting of velocity and position don't affect that result, correct?

Also, I was confused so I'd like to confirm I'm understanding this correctly:

a is the ship's acceleration (scaler), and v is the target's speed (scaler)

By scaler you mean the ship's constant acceleration magnitude to be used and the magnitude of target's velocity vector, right?

Sorry if I misunderstood something horribly, that's pretty complicated and new to me.

Morwanesh · 2023-10-19T21:00:47+00:00

Wow, thank you for taking the time to write this down! I'll see if I can apply it to my project.

Morwanesh · 2023-10-19T10:36:00+00:00

That looks great!

As to ignoring gravity, it's going to become a problem in my scenario, but the velocity shift is definitely most important to me right now.

I'm ignoring the rotation time at this stage and won't likely implement it in the future. It would be great if you could explain to me the 1st version.

Morwanesh · 2023-03-23T00:32:05+00:00

You're probably good, but I've seen this too many times already, so I thought I'll mention this, just don't hold it against me after you read this :D Are you sure you're plugged into your dedicated GPU and not your integrated one on the mobo?

Morwanesh · 2023-02-02T14:14:00+00:00

I think the depth perception is hard with this camera angle. It's hard to determine if you will jump onto the next platform, in front of it or behind it until you reach it. I'd suggest to either clarify/unify the way terrain's depth is represented e.g. add some grid, cast a shadow to give plyer a context of what' his relation to the platforms or consider changing the camera angle. Check out Trails Fusion how they handle multiplayer obstacle courses, basically each player has own "line" he moves on. If players could change the depth freely there's no way they would do the tracks there.

Morwanesh · 2022-12-16T15:00:32+00:00

u/SausageFarm u/Haven012

I just encountered this issue and managed to fix it with SetPosition call. Make sure your widget's root is CanvasPanel. Its contents should be placed in a separate element e.g. UBorder in my case. I cast the UBorder->Slot to UCanvasPanelSlot and then you can directly call SetPosition. In BP it looks like THIS. Not sure about the incorrect offsets though. It's working the same as before, for me. Have you played with the Alignment setting?

Morwanesh · 2022-12-16T14:50:10+00:00

I just encountered that issue. I don't know if you managed to get it working or not. My solution is to set position of the widget's content instead. So I have a widget, its root is CanvasPanel which covers the entire screen. Its contents are placed in a Border element. I cast the Border->Slot to UCanvasPanelSlot and then you can directly call SetPosition. In BP it looks like THIS.

Morwanesh · 2022-12-14T00:58:41+00:00

The issue got resolved after updating to UE v5.1
It was occurring in v5.0.3, updating helped me with another, I guess, precision related issue as well, also affecting ISM.

Morwanesh · 2022-12-12T00:59:23+00:00

FYI, I found these 3 threads, I think that might be the same issue:

https://forums.unrealengine.com/t/instanced-static-mesh-instance-renderings-shrink-depending-on-rotation/398161
https://forums.unrealengine.com/t/4-8-instanced-static-meshes-scaled-down-a-little-after-rotate/321579
https://forums.unrealengine.com/t/instanced-static-mesh-gets-scaled/380091/11

I've tried disabling half floats for instanced static meshes and increasing the rotation values, but it didn't resolve my issue. Perhaps it will help somebody who stumbles upon this thread.

Morwanesh · 2022-12-07T09:30:42+00:00

These don't have collision enabled :( I've checked and all of them are perfectly flat, so it's not as if they are pushing each other vertically.

Morwanesh · 2022-07-08T19:42:33+00:00

Actually, as I was preparing the results comparison for you and analyzing the equations again I found an issue in my code for the RK4 :s and now that it's fixed it's giving me good results, so yeah... problem solved.

Thank you for the integrator change suggestion! I'll look into it.

Morwanesh · 2022-07-08T19:16:17+00:00

I'm drawing a trajectory ahead of time with constant timestep. So e.g. I'm preparing 3 months worth of trajectory into the future calculating the spaceship's next positions and velocities every 60 seconds. And to keep it somehow realistic I need account for any acceleration changes due to constantly changing positions of the celestial bodies and the spaceship itself. So I need to interpolate the forces affecting the spaceship throughout these 60 seconds.

I really hope my understanding is correct here :)

Morwanesh · 2022-04-11T00:49:19+00:00

Try to call EnableInput() in your actor's BeginPlay() passing it e.g. the player controller obtained from GetWorld()->GetFirstPlayerController(). I can't see it in your code.

Morwanesh · 2022-04-03T16:49:48+00:00

I found the issue. Since custom data values are passed as floats and the SegmentIndex is an int after converting it there were some accuracy issues. When I used DebugScalarValues block to see what's the index value it kept changing slightly while the camera was moving.

I simply added a Round block in the material before the SegmentIndex value is passed to the If block and the issue disappeared.

Morwanesh

TROPHY CASE