2016-08-09 ~ Elevations View Fly R1

theo-armour commented 7 years ago

@fgx/owners

Not counting tons of flaky bits, is this the start of a free flight sim?

Elevations View Fly R1

theo-armour commented 7 years ago

Mount Everest

@fgx/owners

And now I can drive Geoff even more crazy! ;-)

I'm building scripts that translate the 3D code into animated GIFs

B&W because of GIF 256 color limit and the 3D has millions of colors. B&W is quick and dirty way of getting around the lmit

Three.js to Animated GIF R7

geoffmcl commented 7 years ago

Hi Theo,

Bravo, for the drive Geoff even more crazy!, but that is just not possible... he is crazy already ;=)) I know that...

The real simple solution to my embedded image was probably the size only... In a normal screen view of an email, or an issue, or whatever, was having a big blat large static image, which you must scroll past, to get to any verbal message, is just tiresome... nothing more...

But, the inclusion of a tiny 256x256 image is not a problem... in a normal screen view of the comment is clear... I can in the same view see, verbal comment, which I am looking for, so I can respond... and the links...

So bravo Theo, you solved the problem... add a 256x256 image at the head of each of your issues, and I would have no real complaint... except ask who is stupid here? ;=))

Use a system that causes me to scroll down, to read the important text, and I will belch... as I have done, repeatedly... ;=))

Put a tiny 256 images at the top of each of your posts, be it static, or animated, is really not important... but would always ask, for what aim?

To repeat the idea: For possible feedback readers, promote the site, the topic, generate interest, ... make the verbal information you want them to read easily see-able,... do not make them scroll over a giant advertising blip - pictures speak a thousand words - image, be it static or animated...

And then there is no problem ;=))

Regards, Geoff.

geoffmcl commented 7 years ago

Hi Theo,

But as you see, the stupid image issue overshadowed your real effort here to create a free flight sim... well at least with keyboard inputs for the flight...

Yes, it is flacky, but a good start...

In a way, this leads into flying a flight from say external file inputs, like the track cooked csv...

And begins to get to a FDM in javascript...

So definitely look forward to your progression on this.. with or without this bloody stupid embedded image question...

What can I do to help? hinder? explain? comment?

Regards, Geoff.

theo-armour commented 7 years ago

@geoffmcl

What can I do to help? hinder? explain? comment?

It's all moving so fast right now that just watching and waiting is probably the right thing

More .CSV files might be good

Also KML files are good. Especially one that look like this one

https://github.com/jaanga/terrain3/blob/gh-pages/data-path-kml/snow-mountain-actual.kml

because I've already built a reader for this style - line feed after each 3 data points

Also how about some research on FDM? Which one should we start with? A good question might be: which one is keeping up with all the drones? I've had people asking me about drone simulators. And drone racing is popular.

And, it's nice to hear that you want to collaborate. I agree.

geoffmcl commented 7 years ago

@theo-armour, yes I want to collaborate, but do not know how!

just watching and waiting is probably the right thing

Ok, I should wait! For what exactly?

Yes, the demo needs to be a lot less flacky... meaning mouse and keyboard inputs seem to not always do what you think...

More .CSV files might be good... Also KML files are good.

But this free flight sim has nothing to do, yet, with a previously flown flight... be it cooked csv, or kml, which I can also produce. So do not understand this...

And on the question of should flown tracks be presented as cooked csv and/or kml, I suppose that depends on what you want!

The cooked csv file offered to you - fid,callsign,lat,lon,alt_ft,model,spd_kts,hdg,dist_nm,update,tot_secs - as a simple array of information... which you seem to be decoding very well, except I question the use of some specific offsets being treated as what they are not... but easy to decode...

The kml offers only lon,lat,alt, with an interesting option of <altitudeMode>clampToGround</altitudeMode>, where the 3rd component, the altitude, will be zero, thus you glue the track to the current ground altitude...

On the other hand, recorded flights will give the real AMSL altitude of the track... not glued to ground level... and in kml that should be meters, not feet... must check that...

And, I have not yet looked at your parsing of the kml, but adding a line feed after each 3 data points should not be a requirement! Simply, do better parsing!

We agree on an array of 3d points, lon,lat,alt... any newlines added, even spaces added, maybe for human readability, should not be a specification! And the parser must overlook, ignore...

But the question here is about the 3D control of the current flight, even before we get to the replay of some historic flown flight. from whatever...

So, it seems this more about controlling a flight, in 3D, over some 3D terrain... the speed of the flight seems presently out of my control!

But to try to describe the oldest, still available, FGFS flight control, using the numeric keypad... in simple terms...

1) Up and Down arrow keys change the ac elevator 2) Left and Right keys control the ac ailerons 3) '5' key centered all... 4) and more...

So a FDM is a set of math equations used to calculate the physical forces acting on the sim. aircraft, such as thrust, lift, drag...

While I can not presently get your first demo to run again, the idea is, not that a key changes a camera view, but that it changes an attribute of the model, like say the elevator, and the FDM calculates what that does to the model/3D view...

In a simple sense, an up arrow should up the elevator angle, and given the speed of the ac, and size of the elevator deflection, the nose would pitch up, and if this generates more lift, then the aircraft would begin to rise in alt... if it creates excessive drag, the the ac would stall, and lose height... crash...

Likewise a right arrow would lower the right aileron, and raise the left... this would cause the model to roll to the right... the FDM would calculate more lift of the left, less on the right wing, so the ac turns right... given some other factor...

So it is not a question of choosing a FDM! We have to define all those variables, and write an FDM to use those facts... which vary for each ac... really, not a simple thing...

So, it was a bit whimsical of me to introduce the big idea of an FDM here ;=)) That can come later... much later...

I would be happy if you can cure some of the bugs in the current demo, and I can wait patiently for that...

But for me, this is the most interesting interaction between a 3D terrain, and an aircraft... Let's try to do something with it!

And in some future version, work on my Android os phone... a big, big rave of Pete... ;=))

And YES somewhere in that is what would be a popular game - racing your ac over a fixed course, with others... WOW

One step at a time...

Regards, Geoff.

geoffmcl commented 7 years ago

OFF TOPIC: More concerning KML format...

Aside from the use of a newline in the <coordinates>, another difference, I note, is -

1) https://github.com/jaanga/terrain3/blob/gh-pages/data-path-kml/snow-mountain-actual.kml

This uses -

 <Document>
  <folder>
   <placemark>
    <linestring>
     <altitudeMode>clampToGround</altitudeMode>
     <coordinates>

2) https://github.com/fgx/fgx.github.io/blob/master/sandbox/flightpaths/vhsk/VHSK-22-01.kml

This uses -

 <Document>
  <Placemark>
   <LineString>
     <altitudeMode>absolute</altitudeMode>
     <coordinates>

A not so subtle difference in the parent XML element...

I can re-gen this XML conforming to the first, if that is correct, and is desired... advise...

But as suggested, adding a newline after each coordinate triplet should not be required...

Maybe Google Earth accepts both forms... as could your flexible decoder ;=))

Question: Is that VHSK kml using altitude feet? That still needs to be checked, and corrected if not meters...

End KML OT:

theo-armour commented 7 years ago

Ok, I should wait! For what exactly?

The status updates usually indicate when things are settling down

KLM and CSV

These would help populate

https://jaanga.github.io/terrain3/index.html#sandbox/elevations-view-path-flight

and

https://jaanga.github.io/terrain3/sandbox/elevations-view-path-kml/

but adding a line feed after each 3 data points should not be a requirement! Simply, do better parsing!

Point taken. Yes, sir. Will do,

While I can not presently get your first demo to run again

Sometimes 'reset view' helps. But , yes, still too flakey

the idea is, not that a key changes a camera view, but that it changes an attribute of the model, like say the elevator, and the FDM calculates what that does to the model/3D view...

Got it.