continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Thanks guys!  Those reports make me happy.  I need to bail on those VJ's for a little while, so if somebody wants to advance it... go for it.  Each VJ (combination drag-surface and drag-puck) needs to be a single control, and proper onValueChange observing wired-up.  Then, it should probably be put into TypeScript.  The new VJ control should follow the API used by other GUI controls.  (For the foggy, VJ = virtual joystick.  I have been experimenting with some simple ones, using BJS GUI, with reports chronicled in recent TWC posts.)

-------------------

On another subject... I have a need for spirographs in BJS.  Here's a nice starter pack:  http://seedcode.com/SpirographN/sgn.html

Ideally, all its HTML GUI should be converted to BJS GUI, and use linesMesh instead of context2d canvas-painting.  BJS Path2d might work well for this stuff.

I don't need as much power as that spiro app has, but it would be nice to match it (adjust-ability-wise).  Even a linesMesh version with NO GUI... would be a huge help to me.

I WOULD like the spiro-pen to be a mesh, sometimes.  I would like to be able to turn-off linesMesh, and sometimes use no-gravity no-emitPower particles, emitted from the pen-mesh, to draw the spiro-flower.  I would like to KEEP the "draw speed" feature.

To go a step further, I want to modify a particleSystem so that particles have random weight/mass (custom update func).  SOME particles fall fast, some slow, some non-dropping.  Essentially, that will make the spiroflower be 3D... because it will get depth-ful (deep). 

If anyone would like to be MY SUPERHERO and build this thing for me us, that would be swell!  Those circles/rotors... I don't care if those happen in the BJS version or not.  The main two things I need to show in my project... are:

- That the tip of each spiro-flower "petal"... is always a loop and never a point (mathematically).  I believe this is true, and I need to show it... for a non-math reason.  I understand that, graphically, it MIGHT be a single point, because the math might calculate a loop SO SMALL as to go below some epsilon value, and can ONLY draw a single point at a petal tip.

- That... no matter the spiro-pen/rotors starting direction, clockwise or ccw, the pen ALWAYS, eventually, returns to the starting point.  What goes around... ALWAYS comes around.  So, I need a draw-direction setting... ebb spirography / flow spirography - just like the toy - start rotating the spiro-gears in either of two directions.

My deepest thanks to anyone who helps me us with this.  If someone DOES "run with it", they might want to tell us, here, so there is not any repeated/wasted efforts.  I'm in no hurry at all, so feel free to create a thread in Projects subForum and form a campfire team... divide-up the project... have fun.  Math-guts, GUI, and render-ways... that's a nice tri-sectioning for a 3-person team.    Thx either way.

[Sebavan]

HeHe,

I would like to be able to help as I love Maths Stuff and I am sure @jerome would jump on it if he had time. Unfortuately, no time for me this month ?

 

 

[Wingnut]

:)  Thx, @Sebavan  Perhaps, to keep from flooding the thread, maybe we should stick-with the "I Might Try It" comments, and shy-away from the "Why I Can't" 

Aww hell... "Why I Can't" posts are fine, too... at least it is commune-icating.  heh.  Thx for the consids, S!  (ps.  3 month wait, no problems)    Thx for pinging Jerome, too.  Unfortunately, I currently owe him around 83,000 favors. 

[jerome]

no time for me either ? unfortunately ... still for while

[JohnK]

Will have a go at the maths and line drawing part and will leave GUI to you or somebody else. Will set it up so that parameters are easy to transfer to GUI.

[Wingnut]

Oh @JohnK, you do SO MUCH "other" work around here... I hate to see you grunt this.  How about...  do it ONLY if you think it would be enjoyable and ONLY if you have no other projects happening?

You are too kind, and I feel I am using you.  I could do the math stuff, too... but... I was hoping that someone could do it... who WOULDN'T go thru 4 nervous breakdowns on the way to success.    Plus, I'm pretty loaded... remodeling a severely water-damaged apartment for/with a guy... in-trade for some free rent.  (which MIGHT equate to enough $$$ to get a touch screen device to test VJ's upon) 

So, THANKS John!  Only if enjoyable and only if nothing more important is happening for you, ok? 

If it feels like work, stop immediately, as you have already done MEGA-tons of work on/for BJS/team.  (hug)

No preset demos needed, either (ok, maybe 1).  And I think... only one rotor needed... for MY sought, simple, 5-10 petal spiro-flowers.

So, I'm thinkin'... yeah, no GUI = fine.  As you say, can be added later, as wanted/needed. 

Imperfection ok, too.  (in case you want to round numbers to hundredths or similar). 

THANKS!

[JohnK]

Am having fun with spirographs. Here is a first draft https://www.babylonjs-playground.com/#0BL86N

 and one with two rotating circles https://www.babylonjs-playground.com/#0BL86N#1

By the way I am making BJS do most of the work by using parents.

 

[JohnK]

Loops an no points https://www.babylonjs-playground.com/#0BL86N#2

Must stop playing and get some tea.

[Wingnut]

FANTASTIC!!  Bogged my browser a bit, but that's a personal problem. 

Well done!  (Wingy dances around like an idiot)  You're just "the cat's meow", JK!

Early particle-from-pen tests... https://www.babylonjs-playground.com/#1BTGPV#14

[JohnK]

14 hours ago, Wingnut said:

You're just "the cat's meow", JK!

Not so much, the patterns you get for standard spirograph ratios do not match those I generate. Back to the drawing board!

[Wingnut]

6 hours ago, JohnK said:

the patterns you get for standard spirograph ratios do not match those I generate.

No probs for my simpleton project.  But, it sounds like YOU might be committing to a "strict and noble regiment" 

Good luck.   I'm envious!   May the horse be with you! 

 If needed, I still have one of these (in plastic purse version)...

And here's a "Gear Daddies" song https://www.youtube.com/watch?v=cvC_rV0qt_Y

[JohnK]

The attempt I have just added to demos and projects sub forum uses much more basic coding and no circles to be seen.

* moderator added the link

[Wingnut]

Nice work, John!   Thank you!

I had another thought (with a possible need for such).

Does anyone think (sim-) gyroscopes would work... in a physics engine?

Here's some fun videos to add to the pondering.   Comments/thoughts welcome.

I also think we could move-ahead on Fibonacci things... pine cones, cauliflower, conch shells, etc.  I LOVE "grown" mesh.

Maybe someday we could modify John's spiro-code... so that it always TRIES TO generate ONLY Fibonacci/GoldenMean/Phi spirals.  Wow!  (1.618-to-1 expansion/contraction ratios?)

I tried a "Fib" playground, recently.  https://www.babylonjs-playground.com/#LTQ15#3

PS:  Just in case you were thinking that the wobbly pole of a child's gyro... draws spirograph flowers or Fib spirals, I think that is not true.  But wouldn't it be something if it DID? 

[Wingnut]

Oooh, I can literally "feel" the community-embracing of that challenge, can't you? 

Ok, so I worked on an old, water-damaged apartment, in trade for some free mason marketeer coupons, and I ordered this...

https://www.newegg.com/Product/Product.aspx?Item=9SIA7WP6495969

(A 1940's coal-powered iPad 4 with enough memory to store a mosquito fart.)

And then I bought one of these...  https://i.ebayimg.com/images/g/ePEAAOSwWjBbTPhf/s-l1600.jpg

(64 gb ram-drive on a lightning connector)

Soooo... I'm going to be touch-screen ready... pretty soon.

Then, I got miserable "fungal pneumonia" for 2 weeks, from working on that apartment without using a respirator.  Brilliant, eh?

See what happens when we "consume" refurbished (pigeon poop) crap?  heh.

[Wingnut]

Alright, my refurbed ipad4 arrived, is router'd, and has installed its latest iOS version.  I Safari-browsed a couple of BJS demos... worked ok.  Sponza demo... good sounds and scene... but slow turning.

Internet Cafe demo... looked good, also slow turning, and browser crashed at the top of the stairs, twice.  I will try to investigate further, after I learn to drive iOS better.  Might need fresher Safari.

Good fun.  This pad is bigger and heavier than I expected.  And it claimed to be "grade B" quality, but I don't see a scratch on it.  (yay).   It's purrrrrrdy.  Too nice for this "campfires and mud bogging" kind of chap.  I need carrying cases, next/soon.

I'm also preparing power and mounting devices for...

-  truck  (view truck's PDF owner's manual + use accelerometer to find some jerking.  Truck has USB jacks & cig lighter socket.  I needed usb to Apple "lightning" adapters for powering from truck USB).
-  boat   (watch movies while fishing)  (boat uses 12-volt car battery/trolling motor)  (Wagan 9.6 amp 4-outlet charging station will be attached to top of boat battery box)
-  mic-stand  (lyrics/songlists) (wall-wart ipad power)

The friggin Arkon heavy duty "ball-stack" mounting arm is $100!  OMG!   (I found a new-but-scuffed for $45)  phew.  I think I can use same mounting arm for all three applications.

Quite off-topic, I know... but I'm excited!  This is my first-ever mobile device, and the first time I've used one.  Baby's first swipes, ya know?

[Wingnut]

Hi gang!

http://playground.babylonjs.com/#UZ23UH#67

Wingy fighting with some GUI again.  ALMOST ALWAYS, I'm the blame... for my GUI problems.  I keep staring and testing. 

Anyway, there is a 6-button vertical stackpanel... and I THINK the stackpanel should automatically set height on each button... so that all 6 buttons FIT into this 50% tall stack.

Butt1 is eating the entire stack-space.  hmm.  

Setting button heights (10%-ish) DOES help the vertical "fit", but not perfect. 

These 6 buttons should vertical size-to-fit automatically, I think (each button having an auto-height of around 17% of stackpanel height).

I think there is something wrong with stackpanel's vertical auto-fitter, or something.  But, more likely, I'm missing something.  Extra eyes/ideas/help... welcomed.  thx.

[JohnK]

Some things for you to play with. In this PG http://playground.babylonjs.com/#UZ23UH#68

Try commenting line 22 or line 23 or both.

Different values on lines 27 and 28.

Use 0, 1 or 2  as a value for line 32.

Just don't ask me to explain ?

[Wingnut]

Weird.  Thx @JohnK.  Unfortunately, lines 20 & 21 are being ignored, in your example.

http://playground.babylonjs.com/#UZ23UH#69

Technically, THAT is how it is supposed to look, except without the rectangle control wrapping the stackpanel.

It is supposed to be a simple vertical stackpanel of 6 buttons... along the left edge, centered vertically.

I think... if the stackpanel control is working correctly, no button vertical or horizontal aligning or sizing... should be needed.

At least it SEEMS that stackpanels once worked that way.

hmm. 

Spacer height?  I hope that doesn't affect the spacing between buttons in vertical stack panels.    @JohnK, did you spurn DK into breaking something GUIsh?  heh.

(thx for work/reply!)

[Wingnut]

https://www.babylonjs-playground.com/#PBVEM#165

I was able to get both button panels displayed... on my world famous Physics Phlyer. 

(both needed rects wrapped around their stackpanels... to get the buttons to correctly stack - not right?)

None of the mis-labeled buttons are observer-wired, yet.  I also added some tinted glass.  Seats soon, I suspect.

Thrusters ARE active... SHIFTED arrow keys, CONTROL arrow keys, and also SHIFTED and CONTROL numeric keypad keys.  But nothing is wired to new GUI buttons, yet.

(This is an "applyImpulse" flyer, so holding-down buttons will continue micro-thrusting.  Thus, the reason for some recent button hold-down questions by me... in "What's New" thread.)

The flyer has 24 thrust ports, so, there will be 24 points where I COULD spray particles in various directions.  I think I will make "see the particles?" an easy user option.

I don't like the way the textures are mapped onto the airfoil fins.  Right side fins need "opposite texture" from left side fins, eventually. 

Physics-active landing skids/rails are planned, too, spring-loaded.  They can be used as skis... in case the flyer is ever used as a bobsled on snowy planets that have gravity (bobsledding tourist business mixed with taxi service)    The skid rails don't turn/steer, so the bobsled must be steered via the 24 thruster ports.  FUN!!!  Accuracy of physics on heightMap terrains... is not quite ready for bobsledding, yet.  A ski's tendency to "track" in a straight line... due to its edges... is not a recognized/honored physics engine characteristic, yet.  It is snow that causes straight tracking... and physics terrains with low friction, are currently ice.  Ice ignores the edges of a ski.

Likely, there will be a "pilot view cam", too, which might remove the two sidebars, and produce a serious "dashboard", which could include some radar/doppler displays and some auto-pilot and auto-correction features/knobs.  The flyer is also a "manual docking trainer" for cargo/passenger runs to space stations and orbiting outposts.  It can also fly into mining caves on 0-G planetary bodies.  SO, precision radar, doppler, auto-pilot, distance/clearance readouts/cam-views, COULD be available on the dashboard view.

But... we lose the "cellphone/tablet shoot-em-up feel" if we make it too complicated, controls-wise.  hmm.

Ideally, in a way, the outside view is for the "zoom around quickly, making taxi fares" cell/tablet play.   The "precision flying thru caves and gentle manual space station approaches and dockings"... are for dashboard/desktop play (big display, lots of buttons/dials, too small for touch screen, but fine for mouse pointers). 

In a way, two simulators in one.  That's "the hope"... someday.

I'm trying to arrange these buttons in a way that is tolerable for both 2-thumb mobile device playing, and desktop playing.  We'll see how that turns-out, later.    I'm thinking the buttons will need to be much bigger, esp for phones.  Even then, maybe touch-pen/stylus button-pressing only, for phones.  Tablets?  Not sure, yet.  Lots to learn. 

I hope everyone is doing well!  Party on!

[Wingnut]

Alright, https://www.babylonjs-playground.com/#PBVEM#168

Held-buttons and single-clicks, active!

Currently, with held buttons, thrust-impulses repeat every 3/10 second.  (see lines 1560 and 1795).

Interesting fun:  When I was touring the available GUI button event observables,  I saw that there was onPointerDown AND onPointerClick.  Interesting!  Hmm. So...

Let's look at the "observer wire-up" on my PITCH UP button:

line 1577...
    butt1.onPointerDownObservable.add(function() {
//     	bobsled.controller.rotNegativeX();  ** Probably could have added this. **
        butt1.loop = setInterval(function(){
        	bobsled.controller.rotNegativeX();
        }, leftpanel.heldButtonRepeatRate);  // every 3/10 sec.
    });
    butt1.onPointerUpObservable.add(function() {
        clearInterval(butt1.loop);
    });
    butt1.onPointerOutObservable.add(function() {
        clearInterval(butt1.loop);
    });
//  ...instead of adding this observer.
    butt1.onPointerClickObservable.add(function() {
       	bobsled.controller.rotNegativeX();
    });
line 1591

At first, I didn't include the first bobsled.controller.rotNegativeX(); in my pointerDown code.  I ONLY started the 3/10 sec setInterval.  OnPointerClickObservable was not yet being used.

And... thus... quick-clicks were failing to thrust.  That's when I added the onClick observers. 

But I probably could have added ** that line ** ... an initial thrust before setInterval, and possibly avoided needing the click observers.  I'll probably test that later/someday.  Meantime, the flyer is acting almost tolerably.

I still need to install Wingnut's "Scene Sucker", yet.  It flies over the BabylonJS Web Site Examples, letting you choose which example scene to fly-around-within.     (won't ever happen) 

[Guest]

can we talk about the texture used for the spaceship?

 

[Wingnut]

Oh gosh yes.  heh.  It needs serious fixing.

Plenty of model vert-slop, too.  It's not symmetrical at all.  Pretty much Gorilla-taped together.    Assorted z-fighting. 

I don't think the crew cab is even sealed enough to hold oxygen supply for passengers/pilots. 

It doesn't like being zipped, either.  The compression would probably cave-in the flyer's rusty mesh.

But the model is not really important.  The white box that the model is parented-to... that's the golden egg.

 

[Wingnut]

Alright, I took #168 for a fly on my 9.7 inch iPad4 tablet... and it works pretty good, touch-screen-wise and FPS-wise. 

Biggest problem... playground failed to enter full-screen mode, when chosen.

Also, playground pull-down menu choices were quite small and barely finger-selectable.  Perhaps a stylus/pen/q-tip/whatever... would be a handy tool for playground-ops on mobile devices.

I think I was seeing 32 +/- FPS while simultaneously thrusting rotation and translation.  Not too bad.  Remember that this is a precision (slow) flyer, not a fighter craft.  So, I got FPS headroom, so far. 

We'll see how that works with the particle sprayers.  During any thrusting, 4 of 24 particle emitters go active... not too heavy.

I'm thinkin'... when in cockpit view mode (dashboard)... the thruster-port particles are turned OFF.  That gives me a little more FPS for dashboard readouts... such as radar and cave-wall proximity sensors (for delivering miners into deep mining caves, which are the most difficult heightMap terrain features to accomplish... OF ANY.)  erf!    I THINK it requires "stitching" a complete model of a cave/mine... onto a "hole" in a (physics-active) heightMap terrain. 

MeshImpostor-only on the cave model (oddly-shaped complex model), so... I need to surround the flyer with little physics-active spheres (many) (14, I predict)... to make flyer "bounce" or "scrape"-against cave walls.  Only spheres can react against CannonJS meshImpostors.  ERF!   *sigh*  Currently, flyer physics is only a boxImpostor, active on the white box master parent/handle, which COULD be sized same as entire flyer boundingBox.

Remember that cool GeometryBuilder tunnel that @NasimiAsl made for me?  Yum!  

A wise taxi pilot would never fly THAT fast... into a mining tunnel.  But... you get the "drift" (drift - NOT something you want to happen to the flyer during a trip into a mine tunnel). 

Precision flying... 1 meter at a time... nice and gentle.  The flyer will handle SOME scrapes and bumps, but if you injure a passenger... you're in "deep kimchee".   

The richer mines have a "fly-me-in" auto-landing system that makes life easier.  But sometimes, the mining generators are shut-down, and you have to go-in "dark and manual", using only your outboard lights, external cams, radar, and prox-sensors.  (pilot view/dashboard view)  Coooool.   Scary!   Slow!    Might use 3D GUI for dashboard... and thus... maybe... get renderTargetTextures mapped-onto GUI 3D panels... something that seems impossible for 2D GUI.  (Used for on-dashboard monitor screens for external flyer cameras - with night-vision option!)

Watch out for spinal compression and broken necks... on hard landings, too (mostly on gravity-ladened planets).   Don't damage the reputation of Hey Taxi, Inc... or you'll get less calls/clients/fares. 

(I live in a giant fantasy land, don't I?  Ain't it great?)   

Update:  PG #176 is here, with seats and some texture adjustments.  I have hidden the physics-active handle, too (the white box mentioned earlier). 

I tried to incorporate some yellow/black checkered material, in the tradition historical taxi-ness.   I think it got uglier.  Is having an ugly taxi... the objective, perhaps?

[Wingnut]

https://www.babylonjs-playground.com/#PBVEM#180

Pilot/dashboard view & external view buttons... begun.  Barely. 

Only a texture on the dashboard so far... none of it is operational. 

Hey, it's a start.  Still pondering whether to use GUI 3D or not, yet (on the dashboard).

RenderTargetTexture from external cameras... needs to be a "live" texture on the dashboard camera-monitor screens (not-yet-created planes)... so, I suspect the dashboard/monitor(s) needs to be mesh, not GUI 2D. 

Possibly, the camera monitor(s) will require a "custom" GUI 3D mesh... not sure yet.  I doubt that anyone has ever tried a renderTargetTexture on a GUI 3D mesh.  In theory, it MIGHT work.  hehe

Each external camera (seen from cockpit view, on dashboard monitors) will probably need PTZ, too.  (pan, tilt, and zoom).  Erf!  I feel a tumor coming-on.

Still thinkin' & testin'.  Fun!   Pilot view cam keeps wandering-off... getting lost in space. 

[Wingnut]

For those following-along at home, I was having some problems with pilot cam position after translation.

For example, in the #180 PG, stay in external view, hold down the right translation button for a few secs, then null trans (stop)... then switch to pilot view.  Flyer was gone, separated from cam2 pilot camera.

This was caused by line 1735:

camera2.position = dash.getAbsolutePosition().add(new BABYLON.Vector3(-1, -2, -90));

I changed it to:

camera2.position = dash.position.add(new BABYLON.Vector3(-1, -2, -90));

...in PG #182.  Seems to work fine, now.

The dashboard is not physics-active, and is parented to bobsled.handle.  Bobsled.handle is the only physics-active mesh in the scene (so far). 

At first, I thought... "Hey Wingy... perhaps when a mesh is position-changed via being a child of an impulsed physics body, the absolutePosition is not updated."

But this is not true.  See PG #183 where I am continuously dumping dash.getAbsolutePosition() to console.  Press a translation button, and we can see dash.getAbsolutePosition() values... tallying just fine, on-console.  Go fig!

Anyway, I have no idea why the PG#180 line 1735 was/is failing.  Maybe others have an idea why #182 line 1735 works better.  No significant logjam, just an interesting curiosity. 

Long Term Thoughts:  In "real" 0-G space flight/mass, there is no "null rot" or "null trans" buttons that INSTANTLY stop the craft from moving.  Instead, they are REQUESTS made... of the craft's auto-pilot system.  Just like the space shuttle and ISS, most micro-gravity space craft have two main modes:  "station-keeping" and "free-drift". 

Station-keeping is quite a challenge.  They use a device called a star-tracker, along-with numerous other devices (control-moment-gyros/accelerometers, etc)... to accomplish it.  In space, everything with mass... opposes everything with mass.  So, things like extending the shuttle's robotic arm... can be a serious challenge IF the shuttle is set to station-keeping during its usage.  The movements of the has-mass robotic arm... is enough to cause the entire shuttle to change position/orientation (a small amount).  Add a satellite/Hubble telescope to the arm's grapple fixture, and it gets much more pronounced/severe.

Although we rarely got to hear it, vernier (tiny) thrusters on the shuttle... made champagne-cork-like "pops" every time a thruster port fired.  Ideally, this would be the case for my physics flyer, as well.  Essentially, when flying the flyer, you are in free-drift mode.  If you ask the auto-pilot to suddenly enter "station-keeping" mode, it immediately shuts off the pilot controls, and goes to work using the vernier thrusters and computer formulas and star trackers... to bring the craft to a halt, rotation-wise and translation-wise.  During this unknown time-period that the computer needs to try to thrust the craft to a stop, it sounds like a popcorn popper.  And if we had the particles turned on, it would be a "particle-puffing party" as the autopilot works its brains out... to get the craft stopped.

This "keep applying thrusters until the craft is stopped" auto-pilot (station-keeping mode)... is a pretty good programming challenge.  Right now, all my thrusters fire at a consistent "pulse" of force, and it is the amount of repeated thrustings... ie. held-down buttons... that sets "accumulated" trans or rot energy.  Using hard-set force-values, the auto-pilot might NOT be able to PERFECTLY stop the craft.  Maybe it can only get "close enough".  But if I give the auto-pilot computer... the abilities to adjust the thrust forces to anything it wishes (during transition to station-keeping)... then... the auto-pilot will "get there" faster and easier, and be able to achieve "perfect stop".

Anyway... I was sort-of imagining the popping and the flurry of particles that will happen... when I ask for station-keeping auto-pilot... during a violently-tumbling out-of-control flyer.  I think it will be fun, and we haven't even STARTED messing with the station-keeping auto-pilot algorithm... when mass changes on the flyer... due to passengers and cargo.  It should be a FUN FUN FUN thing to play with.

It all happens on the currently-invisible white box called bobsled.handle.  Those wanting to experiment with coding-up the station-keeping autopilot... can start right now, using the current flyer playgrounds.  Just get bobsled.handle tumbling, and then turn-on your station-keeping autopilot function.  For now, try to keep your auto-pilot calling ONLY my thruster funcs... such as transPositiveX() and rotNegativeY().  Your AP func will need to periodically** poll bobsled.handle.physicsImposter.getAngularVelocity() and getLinearVelocity() and continue calling my thruster funcs until it gets the numbers as near-to-zero as possible.  Then, it should turn itself off/standby... with a "done" or "I'll keep watching for correctable drift" report.

** The updateAutoPilotProgress() func should be called periodically, via setInterval(), too.  The auto-pilot will need "time" to allow the craft react to its previous station-keeping thrustings, and then "check again"... over and over.  During this time, the craft orientation will need to keep updating, and the particles from the thrusts... need to keep flying.  The station-keeping auto-pilot will take some time to complete... sometimes... perhaps... 30 secs to a minute.  My instant-stop "null rot" and "null trans" tasks... are not realistic.  Each task should take some serious time, depending upon how "out of control" the craft is... when SK AP is activated.   Ideally, there should be a rotational SK AP and a translational SK AP, allowing either or both to be activated.

"SKAP"?  Station-Keeping Auto-Pilot?   Yeah, SKAP it is.  God coders... feel free to code-up various versions of SKAP, for me, if you wish.  Thx!  Good luck. 

PS:  Using @RaananW's cool angularDamping() and linearDamping()... (I THINK they exist)... is cheating.  So, also, is repeatedly multiplying linear or angular velocity by vec3(.9, .9, .9).  Good ideas, but not "legal" in the flyer's imaginary world.