Gimbal Blender Simulation with Clouds

[TheCholla]

The clouds seem to go down in the FOV by 1/8FOV, ~0.05deg. Meaning the pod looks 0.05deg higher at the end.

I apply this data in my LoS, going from -1.82deg elevation at PT1, -1.77deg elevation at PT4. This gives a slightly curved trajectory for Gimbal at 10Nm (PT1), that rises by 480ft.

The equivalent plane trajectory at 30Nm is ~415 Knots, exactly what Edward finds in his scenario with higher clouds. It is straight and leveled. I've added points to look at where the LoS intersection would cross the cloud cover at ~4000m altitude further behind, at about 60Nm. 4000m is in the ballpark for cloud height from the meteorological data of these days. 4000m is also the true horizon at 60Nm so the clouds curve and that's why we see the sky behind while pointing down.

You see the cloud dots in the upper left, they move further as the plane is going in that direction, and the FOV is going up. The pod sees further behind at the end than at the beginning (hence less clouds and more sky).

This is a configuration that fits both scenarios, the question is now whether it's very unusual to find a straight-leveled trajectory consistent with a plane in the horizontal projection of two curvy LoS, or if the close trajectory seen by the pilots may have been due to a glitch of the instruments when looking at a straight-leveled plane.

 

[TheCholla]

In case it interests anybody, I've added a sphere for clouds to see where the LoS intersect a certain cloud height. It's fun because for a certain scenario of the Gimbal (or plane) trajectory, it can be adjusted very precisely because at PT1, only LoS1 can intersect its surface (for the cloud-sky line to be in the FOV). It gives a precise cloud height for each scenario. A strong constraint on the potential trajectories is the vertical LoS having to decrease by 0.05 (to match the change in FOV in the video).

A close trajectory does not have to be a weird U-eye shape to work. I show an example here with the object at 10 Nm. It can be straight, but needs to be climbing by ~400ft. However, a straight close trajectory implies an accelerating distant plane trajectory. But by tweaking the close trajectory you can get a straight and constant trajectory at 30Nm. They go together and this is is all very sensitive to the exact angles.

https://www.geogebra.org/m/xsqu4mgz

Cloud height is about 14000 ft in that case.

With a better understanding of the exact geometry involved, I don't know what to make of it. Sure it's compelling to find a distant leveled straight trajectory that corresponds to a plane flying away. On the other hand, by scanning all possible solutions based on reproducing the clouds, I suppose you had a good chance to find one.

 

[Edward Current]

A close trajectory does not have to be a weird U-eye shape to work.

If your object trajectories inside 10 NM don't slow down, change direction, and go backwards starting around frame 850, then your model is wrong.

If they do, and the object is climbing, then the trajectories have a "weird U-eye shape."

This will be my last reply to you on this off-topic sub-thread. This thread is about a Gimbal simulation constrained to cloud movement. Your Geogebra is a different approach and should be in its own thread.

 

[Edward Current]

I'd like to clarify (or re-clarify) terminology that I've used in this thread: straight-line trajectories and banking trajectories.

By "straight-line trajectories" I mean those without any horizontal acceleration component. By "banking trajectories " I mean whose with a nonzero horizontal acceleration component. A trajectory that's banking to the F-18's left is accelerating to the F-18's left — but I wouldn't use that terminology in my video, because not everyone understands centripetal acceleration. Many only think of acceleration as speeding up, so it causes confusion.

A trajectory that slows down along a straight line, stops (as seen from above), and goes back along that line, to the F-18's left, is not a straight-line trajectory. It's essentially banking to an extreme; the horizontal acceleration component just happens to point 180° from the initial velocity vector. I had located a couple such scenarios earlier, because I was asked if there are trajectories that match Ryan Graves' description. There are — but in 3D they are "weird" as was described above.

The direction that a horizontal acceleration vector points appears to be a function of the final recession velocity. Consider the trajectories of one of the Graves "stops and turns around" scenarios vs. a scenario at the same range that banks to one side (sorry, it's a bit rough-hewn). The arrows are a guess at the direction of the acceleration vector:

.

These scenarios are indicated on the plot with dots in the bottom left:

In the curving scenario, notice the jerk (change of acceleration over time/2nd derivative of velocity). I'd expect the Graves scenarios to have non-constant acceleration as well. In fact, I wouldn't be surprised if all banking/accelerating solutions, at all ranges, feature dynamic accelerations. I'll try to think of a way to check that, because it would strengthen the case for the Gimbal object flying straight and level.

The point is that these accelerating trajectories seem to get more complicated the more you examine them, especially in the close Graves/Lehto range.

I went looking, but I could not find a straight-line solution that starts inside 10 NM. I'm 99% sure they don't exist.

Answering a previous question, I see only a 2.8% difference in the rate of the clouds through the frame between clouds at 2,000 feet and at 15,250 feet. Changing the cloud altitude doesn't cause the cloud motion to slow down any faster or slower, and I don't know why it would. As I keep reiterating, such translational variations don't do a whole lot other than move things around on the plot.

 

[Edward Current]

I measured the average velocity for each second of the oblique "Graves trajectory" at 10 NM — both the speed in 3D (like an airspeed, always positive) and the velocity in 2D (as would be seen on a radar screen, stopping and then going negative) — and made scatter plots. I attribute the weirdness at the beginnings and ends to imperfect bezier handles.

These are not linear accelerations, and they don't strike me as velocity curves of a physical craft. The 2D curve in particular looks like what would happen if reverse thrust were applied that increased at a perfectly constant rate in terms of quantitative force. So, more like math than engineering. I think this further weakens the Graves/Lehto hypothesis that the object was inside 10 NM, and strengthens the case that the object was taking a simple trajectory at 30 NM.

 

[Edward Current]

At long last, here's the video summarizing the methods and findings of my Blender simulation with clouds. Thank you to everyone on Metabunk for contributing to this project!


Source: https://youtu.be/rGzJ9dx3n4o

 

[sitarzan]

...here's the video summarizing the methods and findings of my Blender simulation with clouds...

Props for the vid!

We know a little about the backgrounds of other folk like West, Lehto, Graves, Elizondo, Mellon, etc.

How would you feel about sharing a little about your background?

Asking out of curiosity. Not 'to pick a fight'.

 

[Edward Current]

Props for the vid!

We know a little about the backgrounds of other folk like West, Lehto, Graves, Elizondo, Mellon, etc.

How would you feel about sharing a little about your background?

Asking out of curiosity. Not 'to pick a fight'.

Thank you. My real name is Karl Coryat. Feel free to look me up.

 

[Mick West]

Here's what the camera view looks like when I remove the cloud constraint. This is with a circular path. I hope you can see why models that aren't constrained to the cloud motion are crude and not helpful at this point. The angular precision the clouds provide is critical to getting results anywhere near accurate.

I can confirm this with my own experimental model with clouds. Very small variations *in either rate or turn or azimuth change) can result in the clouds changing directions, or at least significant changes in speed.

The reality of the video is that the cloud motion varies smoothly, with a gradual slowdown through most of the video, then a somewhat more aggressive slowdown at the end. This does not seem consistent with the rate of turn being a fixed function of only the bank angle.

 

[Mick West]

In order to get the "clouds" properly in the frame, I raised them by 2,500 feet; initially I had them topping out at 6,500 feet, and now they top out at 9,000. Additionally I lowered the camera's pitch from –2.0° to –2.3°. Raising the clouds higher without changing the camera pitch, or increasing the camera's downward pitch without changing the cloud altitude, produce similar results, although if we accept the camera pitch as being somewhere between –1.5° and –2.5°, the maximum height of the clouds is constrained (I'll work out all of the numbers).

Do you have more final numbers for this? I'm using a cloud top of 9,700 feet now, but with the target elevation (the camera's downward pitch) at 2.0°. (NAR 2x FOV at 0.35)

 

[Edward Current]

I can confirm this with my own experimental model with clouds. Very small variations *in either rate or turn or azimuth change) can result in the clouds changing directions, or at least significant changes in speed.

Crazy, isn't it? There are so many counterintuitive things in this case, it's no wonder everyone gets thrown off course at some point, so to speak. This is very impressive but you really ought to have the work peer-reviewed in a predatory journal.

Do you have more final numbers for this? I'm using a cloud top of 9,700 feet now, but with the target elevation (the camera's downward pitch) at 2.0°. (NAR 2x FOV at 0.35)

The elevation starts at –2.20 and ends at –2.17, changing linearly, as a first approximation. A much better analysis of the true elevation change could be done. As for cloud height, it's hard to get a precise measure because they vary somewhat in my texture. This is what it looks like when I lower them by 5,635 feet. The highest peaks are right around 6,000 feet.

 

[Leonardo Cuellar]

The reality of the video is that the cloud motion varies smoothly, with a gradual slowdown through most of the video, then a somewhat more aggressive slowdown at the end. This does not seem consistent with the rate of turn being a fixed function of only the bank angle.

Mick, could you update the tool with this feature too? Or create a separate one?

 

[jarlrmai]

I was looking at DCS again, @MclachlanM did some simulations of gimbal with this to show turn circle and ATFLIR angle could match a receding jet.

DCS it appears also now has options to to setup things like cloud height. Whether these show up on the ATFLIR simulation or not I don't know, but you maybe able to create a more accurate DCS version of the simulation with more understanding of the configurable weather.


Source: https://www.youtube.com/watch?v=RxKRrK2aVFI

 

[Mick West]

Mick, could you update the tool with this feature too? Or create a separate one?

I'm working on a new version that's more general purpose - it's a bit of a mess right now though. I'm using this as motivation to learn (relatively) modern Javascript programming techniques, so I've been taking it apart and putting it back together (refactoring) in more modular manner.

maybe able to create a more accurate DCS version of the simulation

Sadly it won't run on my M1 Mac.

 

[Domzh]

@Edward Current i just wanted to tell you im hugely impressed by your work. what a mad man

 

[Mendel]

View attachment 49839

Is it true that the "straight and level" scenario is one where the speed of the UAP is also (approximately) constant?
Was that your assumption going in? or is it a result?

(Apologies, I'm fairly sure you've described this earlier.)

 

[Edward Current]

Is it true that the "straight and level" scenario is one where the speed of the UAP is also (approximately) constant?
Was that your assumption going in? or is it a result?

(Apologies, I'm fairly sure you've described this earlier.)

Yes, that was here. "Straight" in my usage means zero horizontal acceleration. I only looked at banking accelerations; I didn't look at linear accelerations until I tried to recreate the 10 NM "Graves scenario" (which is only a linear acceleration as seen from above). I'm pretty sure there's a whole other family of solutions if you constrain the UAP's trajectory to a straight line as seen from overhead and then change the speed to keep the thing in the picture.

 

[Mick West]

I'm pretty sure there's a whole other family of solutions

Something I plan on doing, when i get some more spare time, is have the tool visually display all possible solutions as parameters are changed - with optimizing flight paths for straightness, distance, and/or constant velocity. This will all be part of a more general-purpose Situation Recreation tool, which I'm calling Sitrec.

https://www.metabunk.org/sitrec/
(not a lot going on there)

 

[Domzh]

.

https://www.metabunk.org/sitrec/
(not a lot going on there)

i cant decide if tony hawk was cooler or sitrec

 

[Mick West]

I've started a thread to discuss Sitrec
https://www.metabunk.org/threads/si...recreation-tool-development-discussion.12354/

 

[TheCholla]

@Edward Current , do all your reconstructions include a steady speed of 360knots for the F-18? And a constant 25000ft elevation?

And unit from your Blender is mile, not Nm, correct ?

 

[Edward Current]

@Edward Current , do all your reconstructions include a steady speed of 360knots for the F-18? And a constant 25000ft elevation?

And unit from your Blender is mile, not Nm, correct ?

The speed varies according to the onscreen calibrated airspeed — offhand I think the TAS stayed between 348 and 355 knots — but that didn't really produce measurable changes over the constant-speed version at 350 knots, since position is translational. The F-18 is steady at 25,000 feet altitude, but it follows the curvature of the Earth under it, which is significant because that involves an angular quantity.

Not sure about your last question. In my model, one meter = 50,000 feet. All of the results I've communicated have been in nautical miles, which I think I always specify, except for some tweets where readers may be unfamiliar with nautical miles, in which case I convert and just say miles. Generally I would measure a distance in the model in meters and then multiply by 8.23 to get NM.

 

[TheCholla]

The speed varies according to the onscreen calibrated airspeed — offhand I think the TAS stayed between 348 and 355 knots — but that didn't really produce measurable changes over the constant-speed version at 350 knots, since position is translational. The F-18 is steady at 25,000 feet altitude, but it follows the curvature of the Earth under it, which is significant because that involves an angular quantity.

Not sure about your last question. In my model, one meter = 50,000 feet. All of the results I've communicated have been in nautical miles, which I think I always specify, except for some tweets where readers may be unfamiliar with nautical miles, in which case I convert and just say miles. Generally I would measure a distance in the model in meters and then multiply by 8.23 to get NM.

Got it, distances are in meter in your model, makes sense now.

 

[TheCholla]

Is there a way to extract the coordinates from your F18 and 30Nm plane, so we can compare the trajectories across different models? In a tabler for example, that would be very helpful.

 

[Edward Current]

Is there a way to extract the coordinates from your F18 and 30Nm plane, so we can compare the trajectories across different models? In a tabler for example, that would be very helpful.

Not that I know of. But in my model, the shape of the F-18 flight path has little importance. It just gets the aircraft in roughly the right places, and from there, its rotation parameter (discussed here) takes over. In the Blender file, the object that animates the F-18's rotation is called "Jet advancing," with the F-18, camera, etc. parented inside it. The animation is keyframed every two frames for much of it. It's called "Jet advancing" because in addition to the rotation animation, its translation is taken from the "Jet path" object, by way of a "follow path" constraint.

Admittedly this was a kludge, but it was highly effective and in the end makes no difference. Someone could write a ML program to fine-tune the F-18 path from frame to frame, and the results would be the same. (Arguably that would be less physical, since a jet isn't a train on rails always pointing in the exact direction it's headed.)

 

[TheCholla]

Thanks, got it.

In the end, what is your explanation for the lowering of the clouds, in your scenario? I still don't get how two planes flying leveled and staying at roughly similar distances, would create this lowering of the clouds, especially with the flat cloud cover you have in your model. Is it there in your video reconstruction? It's not very clear.

I am also not sure how you can explain the change in size/shape of the object with your scenario, with no change in the distance from the F-18, and a very little change in angle of incidence by which the plane is seen. A 3% change in angle of incidence would create a 20% increase in the size of the glare? And quite a change in its shape?

 

[Mendel]

I'm pretty sure there's a whole other family of solutions if you constrain the UAP's trajectory to a straight line as seen from overhead and then change the speed to keep the thing in the picture.

I'm really interested now in building an intuition of whether the straight-line, constant altitude UAP path is a solution that always pops up, or whether it is rare. Like, if I simulate a UAP that is banking, or speeding up, would the simulated observation data still resolve to a (false) straight trajectory? If the answer is "no", then the fact that you found one becomes more significant!

 

[Mick West]

I am also not sure how you can explain the change in size/shape of the object with your scenario, with no change in the distance from the F-18, and a very little change in angle of incidence by which the plane is seen. A 3% change in angle of incidence would create a 20% increase in the size of the glare? And quite a change in its shape?

3% does not sound like a lot, but it's kind of meaningless here. The glare size is not a % of 360°.

What angles is the glare at full size and very small, say in the Falch videos. What's 20% of the angle change needed to go from full size glare to negligible glare? Looks like it does it in less than 45° to me. So 20% of 45 is 9°.

 

[Edward Current]

In the end, what is your explanation for the lowering of the clouds, in your scenario? I still don't get how two planes flying leveled and staying at roughly similar distances, would create this lowering of the clouds, especially with the flat cloud cover you have in your model.

This is one of those counterintuitive things that seems wrong based on common sense. Let's take the hypothetical that the 30 NM straight-and-level trajectory is what happened. The clouds lower simply because that's where the object was flying. Consider:
1. Looking at the plot below, if the object were a little farther away but everything else were the same (red square), the object would have to climb and bank a bit to stay in the middle of the picture — with the lowering clouds, as we see.
2. If however things had happened differently and it wasn't climbing at that farther range, but rather was maintaining altitude, the object from the F-18's perspective would stay at the same elevation as the clouds, rather than rising away from them, as it does in the original video.
3. Since the ATFLIR keeps the object in the center of the frame, under the alternative situation described above, the clouds wouldn't lower in a video taken by the F-18.

Put another way, if a straight and level object had been considerably closer, the Gimbal video would have shown the clouds moving up in the frame, until we didn't see any sky at all. I feel like that video would have looked much less like a crazy physics-defying UFO, and more like a plane, because we've all been in an airliner seeing a lower-altitude plane moving across the clouds.

It's true that if two planes are flying along the exact same path, with the same speed and altitude, they would maintain the same elevation against the clouds from the other's perspective. But that's not the case here; the F-18 and Scenario #5 are offset by 6,000 feet altitude and a couple dozen knots airspeed. That — in three dimensions — is what makes things mind-bendingly difficult to figure out using intuition.

 

[Edward Current]

I'm really interested now in building an intuition of whether the straight-line, constant altitude UAP path is a solution that always pops up, or whether it is rare. Like, if I simulate a UAP that is banking, or speeding up, would the simulated observation data still resolve to a (false) straight trajectory? If the answer is "no", then the fact that you found one becomes more significant!

We could test this. I'm not exactly sure how, but it seems doable at least on a limited, non-rigorous basis. Perhaps you could blindly come up with a trajectory, listing some specifics:
1. Initial distance
2. Initial altitude
3. Initial and final true airspeeds
4. Altitude change
5. Turn rate

A resulting simulated video wouldn't look anything like the original, but that's beside the point.

Then maybe we could do several other sample trajectories. Each time, I'd go looking for a straight and level solution.

Does that sound right? I could be way off here; I may need to try it to see if it's even feasible. TBH each one would be a tedious pain in the ass, but I'm as interested in that answer as you are.

 

[Mendel]

Does that sound right?

Well, that's the deluxe version.
I was thinking of starting simple, i.e. in 2D, and a fixed observer track, and change the observed object's path, and build from there—your list looks like a good place to end up at. I'm hoping to get around to it sometime this week.

 

[Edward Current]

I was thinking of starting simple, i.e. in 2D, and a fixed observer track, and change the observed object's path, and build from there—your list looks like a good place to end up at. I'm hoping to get around to it sometime this week.

2D would be slightly simpler. But the altitude difference between the observer and object is important, so I say let's just start in 3D, but maybe starting with an object that doesn't change altitude. I learned a (very basic) technique that could make this a ton easier — constraining the camera so it tracks a selected object. So, setting up the sightline for any given test trajectory will be trivial. To do that, I'll have to set up a simplified version of the F-18/camera without the nested, keyframed rotations like the camera roll...no problem.

This experiment should be in the other thread, though.

 

[TheCholla]

@Edward Current , would you say that in order to be precise in the lines of sight you retrieve, your simulation needs to be very accurate in how the clouds are represented, compared to the original video? Because the clouds is all the data you use to reconstruct the paths.

How do you measure how your sim matches the cloud motion at any point of the video, to be confident that's where the line of sight should be? Do you have an algorithm for that? Or is it based on visuals, i.e. looking at the sim versus the vid?

 

[Edward Current]

@Edward Current , would you say that in order to be precise in the lines of sight you retrieve, your simulation needs to be very accurate in how the clouds are represented, compared to the original video?

The accuracy of the clouds representation is related to the accuracy of the final results, yes.

Because the clouds is all the data you use to reconstruct the paths.

Not true, but it does determine where exactly the camera is pointed left-to-right at any time.

How do you measure how your sim matches the cloud motion at any point of the video, to be confident that's where the line of sight should be? Do you have an algorithm for that? Or is it based on visuals, i.e. looking at the sim versus the vid?

If a cloud feature at the left edge of the picture on frame x reaches the right edge at frame y, then that's a pretty good indication that the same thing should happen in the simulation. There's an uncertainty of maybe 4 frames, max, which at the beginning is roughly 6% and less than 2% at the end. That's a lot more accurate than trying to convert the dynamic bank angle to a series of circle-arcs and then hoping for the best. That produces garbage like this — totally useless.

 

[TheCholla]

From your README, your reconstruction is primarily based on the cloud motion, is what I understand.
"The idea of this simulation is to recreate the F-18's flight path from the movement of the clouds rather than the banking data, and put a camera on the aircraft and actually shoot a simulated cloud bank with the same 0.35° field of view as the ATFLIR camera, consistent with all other data available onscreen. Once the cloud movement was recreated, I put in an object at various distances and altitudes; then, for each of those objects, I found a trajectory that would keep the object near the center of the camera's field of view. "

My question was not how the cloud features needs to be represented, yes they could be a flat layer of cats. By precise I meant that the cloud cover slope, and perspective in the FOV, must be really close to the original, because that's what determine the F-18 path, and the reconstructed trajectory of the object. That's why I ask how you measure that, and I understand from your last point that this is done manually, by eye.

In the second half, the clouds in your sim look very close to the video, but not so much in the first half. The slope of the cloud cover is more pronounced, they disappear lower near the bottom right edge than in the video (see below).

To me this means you have a more pronounced banking angle, and that would explain why you find faster speed of the object than my model at the beginning, because your lines of sight diverge more.

 

[Edward Current]

My question was not how the cloud features needs to be represented, yes they could be a flat layer of cats.

I edited my answer when I realized what you were asking.

In the second half, the clouds in your sim look very close to the video, but not so much in the first half. The slope of the cloud cover is more pronounced, they disappear lower near the bottom right edge than in the video (see below).

You should do one that's more accurate.

To me this means you have a more pronounced banking angle, and that would explain why you find faster speed of the object than my model at the beginning, because your lines of sight diverge more.

I don't grasp that reasoning. How would simulated clouds move according to your method, if we put a camera on your sightline? Do you think it would be closer to the original?

 

[TheCholla]

I don't grasp that reasoning. How would simulated clouds move according to your method, if we put a camera on your sightline? Do you think it would be closer to the original?

I don't know. But my model does not use the clouds as a primary source of data, I'm using the old-school method of constructing turn circles/tangents. I reckon it has some large uncertainties, but to the point of finding a difference of speed of 100 Knots, in two segments that have constant banking, I don't know. (Source : https://www.metabunk.org/threads/gimbal-3d-analysis.12303/post-267003)

I really think your scenario should be tested in a DCS simulator. Like it had been done a while ago here, but with a plane at 30Nm, moving like in your reconstruction. I wish I could do it, but I don't use DCS.

 

[jarlrmai]

Maybe I should setup a Just Giving to get interested people to buy the F18 pack for DCS. However I feel if the DCS sim was a slam dunk against Mick or Edward's receding straight line steady speed model then Alpha Check would be all over that in a video.

I'm happy to put the time into learning to use DCS to simulate it, the problem is there's no guarantee that it is configurable/accurate enough to recreate what we want to see (3d cloud modelling with enough options to be able to set cloud type/size/altitude) then see those clouds on the ATFLIR. So the money might just be wasted.

@MclachlanM Had DCS + F/18 and seemed willing but they've not posted for a while. What was missing from their recreation was the clouds in view of the ATFLIR iirc.

It does amaze me though after all this time that the DCS pilots are not all over recreating these videos etc, the questions we are asking have probably been gone over in detail by the dev team for DCS/F18 pack as well. They would good insight, but do not seem that interested.