2016-08-09 ~ Elevations View Fly R1

[theo-armour]

@fgx/owners

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

Elevations View Fly R1

[theo-armour]

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]

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]

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]

@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]

@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]

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]

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.

FDMs

There's a bunch here:

http://wiki.flightgear.org/Flight_Dynamics_Model

Are there any that you prefer. Or which ones should I start to chew on first in order to see what it's all about?

racing your ac over a fixed course, with others... WOW

Abracadabra. Your wish (list) is my command (line).

---

Currently working on reading KML files

The goal is to be able to view all the following in 3D

http://caltopo.com/find

With a chase camera.

Also working on auto-magical marketing: the code you write sells itself as you write it. See:

https://jaanga.github.io/terrain3/

Both left and right menus are generated via the GitHub API.

[theo-armour]

@fgx/owners

Elevations View Path CSV R2.1

Things are beginning to look quite nice in here.