continued_at_new_forum The Wingnut Chronicles

[Pryme8]

Have you tried to use a linear joint, that would be more realistic as far as landing gear 'suspension' is concerned?  The angle joint would just be the thing that articulates it up and down into the chassis.

I guess if you were doing a trailing link landing gear, the elbow/angle joint would be right, but a linear gear would still be the thing that absorbs the impact.

[Wingnut]

A vertical shock-absorber-like thing?  Spring-loaded?  Yeah, I mentioned that in an earlier post, but it's just so boring.  I think they are called SliderJoints. 

Daddy long-legs are so much cooler and offer lots of motion/action.  Lots of spring-loaded, angle-range-limited hinge joints.  Not sure I can do it, though. 

I "fought-with" lockJoints most of the day, and although they have excellent springy-ness, I can't seem to get them under control.  They are IMPOSSIBLE to "angle".  They always want to aim along an axis, and if they get impacted hard, they will actually bounce-around to a different axis (ie. suddenly the landing gear is on the OPPOSITE side of the main craft, where another gear strut is already installed).

http://playground.babylonjs.com/#RLKVFF#21

Keys active: x, y, z, shifted-x, shifted-y, shifted-z  (all impulsing).  Just one active lockJoint... sticking out sideways. 

The blue cyl (with boundingBox showing) is parented to the green box.  And the joint is set between that blue cyl (bodyA) and the pink cyl (bodyB).  Yet the pink bodyB is not rotating WITH the blue bodyA (but it IS rotating-around WITH the green box/blue cyls "group"). 

The lockJoint sort-of "detected" that blue cyl was parented to green box, so it "attached" itself to the center-point of the summed bounding-area defined by the green box and all 4 blue legs.  In brief, it attached to the GROUP that happened when all 4 blue legs were parented to green box.  The pink thing IS rotating with the green box, but it doesn't care about the animated rotation of the blue cyl which is directly-attached to the joint.

Goofy.  The lockJoint sort-of ignores (transform/orientation-wise) the attached mesh IF/WHEN that mesh is a child of other mesh.  hmm. 

The joint's bodyA.shapes array contains 5 objects... a green box and 4 blue cyls.  One end of the joint is attached to FIVE objects!!!  Weird!

I even tried "shifting" 4 of those shapes out-of that array, hoping that ONLY the blue cylinder would become the joint's lone bodyA.shapes[0].  And if you "pop" 4 objects out-of the joint's bodyA shapes array, you also need to pop other things, too.  It's a long story, and not very exciting for TWC readers.  See lines 458-469 if you're one sick puppy. 

LockJoints don't seem to allow ANY limits, either.  (Can't prevent them from flexing TOO FAR during hard impacts/impulsing)... like stiffness/damping setting.  They are a reasonably stupid joint.

I only hacked just SO deep, and then bailed.  But I was WAY down there, messing with the axes on the joint's rotationalEquations.  This PG has a VERY MESSY mad-scientist workbench.    Lot's of experimentation debris in there.  heh.

No joy.  Love that springy-ness, though.  Can't seem to use it for anything useful.    Thx for input.  Your idea is on the back burner, but still a good one.  SpringJoint experiments are coming soon, but Cannon spring constraints have failed me, so far.  Still testing.  Even if I AM able to turn-on a Cannon spring constraint, they also look like a "stupid" joint... not having any built-in toys to keep the spring axis-aligned (like on the automobile shock-absorber).  To make a spring-loaded "piston" move axially-ONLY, the piston might need "guides"... little physics-active bumpers to keep the piston from tipping/swinging.  That should kill FPS rather nicely. 

One ugly question comes to mind.  Can TWO joints be active at the same time, between the same 2 bodies?  In other words, sliderJoint + springJoint = spring-loaded slider joint?  hmm.

[Wingnut]

Hey guys.  I wanted to say that textWrapping is already available in Babylon.GUI - http://doc.babylonjs.com/overviews/gui#textblock

So, ignore my request for word wrap in a previous post, here.  Leave it to @Deltakosh to have cool and powerful features installed... well-before anyone asks for them. 

Friggin' genius... (and an accommodating sweetheart)... that Deltakosh guy.  He's so far ahead of the game that we can see him in our rear view mirrors. 

Docs-in-playgrounds system, ready to roll, 100%.  It's SO gooooood.

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

But while I'm here, what the heck... I'll ask a question:   With AdvancedDynamicTexture (ADT) for a box-mesh (not full screen), is it possible to put a simple button on ONLY ONE SIDE of the box?   Anyone know, off the top of our heads?  (thx)  I have more reading/studying to do.

I'm working on @Mezzorio's "Commanding General - Inspecting The Troops" long line of sprite-like photo panels.  Each panel is a box (which will soon have photos of people on the front sides), but I really want the button on the front face ONLY (if possible).  I might use a plane, positioned on the front face of the box.  Anyway, here's a 6-face version.

https://playground.babylonjs.com/#IDDZ4K#6

(use control-drag to truck the camera along the troop line-up)   

Work happening in line 86 area.  Button is mapping to all 6 sides of the panel (expected, but not wanted).  Also the button has killed the shadow on each panel.

https://playground.babylonjs.com/#IDDZ4K#7

And if anyone knows WHY those shadows are narrower than the mesh, I would be glad to listen to any words about that, too.    (thx)  ALL advice welcome. 

As you can see by line 87, I am about to try full-screen ADT, and activate mesh-tracking.  That should eliminate the 6-face button problem, but other problems may arise. 

I don't even know if Mezz WANTS a button or name-label, but I thought it would be a cool add-on, and handy for stuff, like popping-open a mini-bio.  But folks could click-on the sprite-like panel, too. 

AND, for the 6-face issue... I could use planes instead of boxes, but Mezz wanted to instill a "depth-ness".   Shadows do that somewhat, but "thickness" also helps... so I used boxes.     All advice welcome, even from @Mezzorio and @brianzinn   We've been talking about this project in this thread.

update:  [ link ]  (control-drag handy)  I'm using aux planes for simplebutton name tags - working well, it seems.  Shadows are back, things are looking kind-of nice.

[Mezzorio]

On 24/08/2017 at 2:54 PM, Wingnut said:

I don't even know if Mezz WANTS a button or name-label, but I thought it would be a cool add-on, and handy for stuff, like popping-open a mini-bio.  But folks could click-on the sprite-like panel, too. 

 

Buttons are my step after changing over to Babylon and something I had no idea was even possible so 10/10 thanks for showing me your chronicles too! lots of useful stuff amongst these 40+ pages haha! Time to dive in!

[Wingnut]

  Hi Mezz!  I think you can concentrate upon TWC posts that happened in the past day or two.  heh.

Nothing overly important, here.  Main thing... ya got some stuff to show on Monday.  I screwed-up your makeLight(), makeGround(), makeSkybox() jump-table-like structure a bit, but you can recover that.  We could also use a makePanel() inside of "the big for-next loop" that builds the lineup, but none of it is necessary... unless you need to satisfy a programming instructor, or maybe later, if the project gets huge.

No time for me to advance anything today.  The band is playing the county fair tonight, and we have a bunch of prep.  "dedicated to the Classic and Southern Rock, such as Merle Haggard" ??  That's stupid.  Merle Haggard is about as "rock" as opera music.    Never put a drummer in charge of PR!  heh

YOU could advance Brian's moveLeft/right animator and assorted other crap... as wanted.  And, you know, you have to "build" a url for each panel, using the name variable.  URL = baseAddress + "/" + name + ".png";  A new image URL needs to be built for EACH time through the loop... using the ever-changing name variable.

You probably know all that.  Good luck.  Hope you get it working as you wanted.  I'll be back in 12-20 hours, if I don't freeze to death playing bass/singing... outside... on this likely-chilly night in Michigan's U.P..  brrrrr.    Party on!

[Wingnut]

Hi gang.  Ready for a brand new playground?  https://www.babylonjs-playground.com/#11JINV#7

I was thinking about... HOW fancy can Babylon.GUI textBlock borders... actually get? 

Not too bad, eh?  SVG file for the border, slightly-squished textBlock in the middle.  Purrrrrrrrdy.

If indeed... we have an SVG document inside of an <svg> node nearby, then THAT MIGHT mean we can use JS and SVG and other DYNAMIC context2D fun... to generate fancy borders REAL TIME!  On the fly!  Or should I use the term "JIT"  - just in-time.  Anyway,  this rocks.  We're nearing "build your own GUI widgets", eh?  Cooooool.

This playground doesn't do anything fancy like dynamic-genned ornate borders.  It loads one... into a Babylon.GUI "image" control.

Then I spent 3 hours beating the hell out of every property on text1, trying to make it do vertical scrolling.  Nope.  Web searches -> nope.  It seems that scrolling context2D "stuff"... is quite a miserable task.  Web experts recommend abs-positioning another HTML element (like a div, with scrollbars/overflow stuff on-board)... directly atop the text area.

Well, tell that to my orbiting camera, which will easily expose THAT fakery, in short-order (quickly).  One little pan of my arcCam, and that absolute positioned "black area" would become absolutely out-of-position. 

I think there's another way.    I discovered that these AdvancedDynamicTextures that get .CreateForMesh(plane) [line 44] ... they are mapped onto the mesh.material.emissiveTexture auto-magically.  See line 87:  console.log(plane.material.emissiveTexture._context);

That returns a context2D!  Whooda thunkit?  A guy could paint onto that thing, in real time, perhaps.  But more importantly, I think I could create TWO planes, one for the pretty border SVG, and another for the center text area.  Put an ADT on each one, put the textBlock on the inner plane ADT, and use plane.material.emissiveTexture.vOffset... to get some scrolling done!

Of course, there's only SO MUCH texture-sliding you can do with vOffset... before something undesirable happens... like wrap-around or clamp streaking.  So, perhaps more trickery is needed.  Yes, vOffsetting an .emissiveTexture IS a very strange way to attempt vertical scrolling text, but "strange" is what we do 'round these parts, right?  Party on.

PS: Anyone still following the great "springy landing gear" project might want to see the latest.  Only one leg active, but I was FINALLY able to "set" a springy lockJoint at an angle (the pink thing).  Before, they were always oriented perpendicular to the green lander (sticking straight out-of top, bottom, sides).  This one "droops", or I have somehow managed to move its center/idle position.  It looks to be about 60 degrees.  Add 3 more, put some mass on the green box, and watch it try to land on those springy legs.  Should be a hoot!  Right now, it is not very exciting, but it gives me hope for using the wonderful springy-ness of the lockJoint... for landing gear.  x, y, z, shifted-x, shifted-y, shifted-z keys active.   Massive joint1 hacking in lines 261-271 (Wingnut feeling-around, blindly.)

Aside:  An interesting picture from a motor boat traveling on a Texas interstate highway.

[GameMonetize]

On a side note I plan to add scrolling capabilities to GUI (one day :))

[Wingnut]

That's great news, DK!  Thx.

Meantime, I did some more screwing-off.  https://www.babylonjs-playground.com/#11JINV#12

Just... goofy.  Perhaps renderGroups and layerMasks, and perhaps renderTargetTextures... could do fun things here.

For example, what if we used a renderTargetTexture on a PERFECTLY-sized plane in the middle.  "Feed" that RTT from another camera... located FAR FAR away.  That camera is doing a slow-crawl across a TALL plane full-of textWrapped ADT textBlock!  That would work great!  No need for ceiling or ground to block view of undesirable things.  Perhaps, next version.  I wonder if that RTT feed can have a transparent background.  We need to see the (future) skybox... between/behind the text words and characters.  hmm.   Fun!

Methods of delivering text within playgrounds... could be an early step towards playground-based tutorials.  As an added super-challenge, everyone is invited to add a WONDERFUL feature.  When the words "text1.height" and "textADT.vOffset" come into view, command the program to automatically scroll the EDITOR to approximately line 80 (at top of editor)... and then flash the highlighting/colors of lines 95 and 107 (for maybe 15 seconds).  Leave both lines highlighted afterwards, IF the Monaco editor will allow that (probably not).

Likely, this will NOT be an easy task. 

The objective... is to blatantly SHOW the user... where in the editor code... those two lines are located (using a trigger of some kind, such as testing the value of textADT.vOffset.)  Good luck.  Massive praise for anyone who accomplishes this.  thx!

[adam]

On 8/28/2017 at 7:54 PM, Deltakosh said:

On a side note I plan to add scrolling capabilities to GUI (one day :))

Do you think this is the approach you are going to take?

http://blog.teamtreehouse.com/create-vector-masks-using-the-html5-canvas

 

[GameMonetize]

It is my current plan

[Wingnut]

Errf, base URLs for the forum have changed.  I think we just got 10,000 broken links throughout the forum comments.  5000 of them are likely in MY posts.  *sigh*

Whelp, anyway, big clean-up chores ahead for Wingnut.  I managed to re-discover the "five-subforum searcher" for BJS.

http://www.html5gamedevs.com/index.php?app=core&module=search&controller=search&type=forums_topic&nodes=16,28,29,30,31

And I guess the forum itself is at http://www.html5gamedevs.com/index.php?app=forums&module=forums&controller=forums&id=16

Links from one post to another post?  I don't want to think about it.  I've got a knotted stomach from worry.  Somebody go check if they still work... I'm scared to look.

I just got an alert from the forum software.  200+ new replies.  hehe... oookay.

[JohnK]

Like you sad to see that links from one post to another produce a sad face.

[adam]

@rich can probably just switch SEO-friendly urls on again.

[Wingnut]

Whatever that means... I'm all for it. 

Those who have direct links on home webpages... that target "last post" in some thread... here's the format for that...

http://www.html5gamedevs.com/index.php?app=forums&module=forums&controller=topic&id=4983&view=getlastpost

That's a link to get you to the last post in Tutorial Talk.  (I'm probably the only one who uses these.)

Thank goodness... &view=getlastpost ...still works.  Otherwise ya need a "&page = number" parameter...

http://www.html5gamedevs.com/messenger/?id=2213&page=14

(That was a link into an on-going private conversation with 4-5 members.  It will need a new format, too.)

At least I have a root canal to look-forward-to... in a few hours.  hehe.  Nah, just kidding, it's only a front end alignment on my pickup truck.

[Wingnut]

Okay, back to physics for a moment, friends.  In another thread, @RaananW recently reminded me of the min and max nativeParams that can be used in OimoJS physics (hinge) joints.

Continuing the PG series from the other thread,  I started by updating to version 7, which tests the Oimo hinge joint... with some simple min and max settings (line 70).  It works just fine.  Use clicks and shifted-clicks (multiple fast ones ok)... to impulse the min/max angle-constrained Oimo hinge.  Love it. 

Take note that lines 94 and 96 (the click and shift-click impulsers)... are applying both X and Z impulse.  It is trying to break the hinge... trying to make it go sideways.  But, the Oimo hinge is holding-true to it's axes settings... and properly performing single-axis motion.

Now, onward to CannonJS.  As far as I can tell, nativeParams min & max don't work at all... for Cannon hinge joints.  BUT... it's me, Wingnut... God of Mistakes. 

https://www.babylonjs-playground.com/#8PQK71#9

Min/Max settings are at line 64... along with an attempt at a spring setting, which I don't understand what-so-ever... but I'll get there.

AND... take notice of lines 91 and 93... the very same "angular" impulsing on both X and Z at the same time... trying to make the hinge spin on an incorrect axis.

Try some clicks and shifted-clicks.  Oh boy!  The Cannon hinge joint seems to be a multi-axis thing.  It will "rock" or spin on ANY axis (wrecking-ball/tether-ball).  Wow.

BUT... it's Wingnut - brain-damaged Fibonacci junky.  Mistakes aren't just likely... they are inevitable.      While the therapist tries to fix Wingnut's brain, this darned Cannon hinge is still refusing to accept min/max angle constraints, and refusing to hold-true to its assigned axial orientation.  Any ideas, folks?  (thx!)

[Pryme8]

@Wingnut word round the block is energy.js is gonna be coming round here soon.

[Wingnut]

http://www.html5gamedevs.com/topic/17530-early-test-c-physic-engine-port-emscripten/

Thanks for the hope, but that rumor is almost 2 years old.  And besides, we can't count-on a new engine.  There could be 2-years of work just to get the bugs out-of the integration-to-BJS, IF it happens at all.

I have to work in-the-now, and I would really like to get something done about https://github.com/BabylonJS/Documentation/issues/454

Joints and compound (parented) rigid-bodies, yep yep yep.  Appropriately and correctly "fingered" by DK as some of the most-asked-about subjects in Q&A.  Those subjects are also the least-learned-about subjects, so there's very few experts nearby. 

At least that Cannon heightMap hassle has been fixed.  That one entangled me for 6 months, with nobody learning WITH me(well, Raggar, a tiny bit), and nobody around to ask for help.  That has to end.  Six months to solve an issue as important as physics heightMaps... that's just terrible.

So, I need to learn learn learn.  I am likely NOT the best choice to write the Physics Joints and Physics Parented Compounds tutorials.  Well, maybe I'm an OK choice for writing, but perhaps not so OK for the necessary pre-writing research. 

Are the terms min and max REALLY good choices for inclusion in nativeParams?  Can anyone FIND properties named min or max upon an Oimo or Cannon joint._physicsJoint?  I couldn't find them... but I make mistakes.  Is it important for nativeParameters to be named precisely identical-to the true native parameter names?  Dunno.

Needless to say, I'm not looking-forward-to Energy.js at all.  From what I have heard, EnergyJS will have difficulty "following the template" of our OimoJSplugin or CannonJSplugin.  In other words, more docs... special docs, and possibly difficult to teach... due to no knowledge carry-forward from Oimo and Cannon plugins knowledge.  EnergyJSplugin will likely be quite different from the other two plugins.  Work work work.

Meantime, I need all the help I can get... with the current joints (and parent/child-based compounds).  They are what needs documenting.  Ragdoll avatars/players are going to EXPLODE in the future (literally), and we (I) are not ready to answer all the inbound questions.  Physics for bone-transformed mesh?  I don't even want to think about THAT.  But, there's been SOME work done ... making impostors track bones/boneMesh, so YAY for that!

The interface between BJS and third-party physics engines... is an ugly, stinky swamp.  Some BJS superheroes were kind enough to lay-down some planks, so we can, at least, INVESTIGATE the swamp.  It's now time to fill-in the swamp, and build a research institute there... just to force the brain-sucking skeeters and leg-chewing gators... to leave.  (Wingy joins his dog, hiding under the fridge.)   

[Wingnut]

Hi guys/gals.  I was recently thinking about physics-active player "feet" or shoes... and how they might slide on a physics heightMap.  Mainly, I wanted to test if a physicsBody had MORE tendency to slide downhill... upon a "crease"  or "ridge" (along an index line)... than upon flat surfaces.

https://www.babylonjs-playground.com/#B5BDU#54

As you can see, whether upon a ridge, or upon a flat surface, slide tendencies and slide speeds... are about equal.  (yawn)  Such excitement, eh?

[Pryme8]

hmmm, you would think friction would apply differently due to surface contact area but I don't know if any of the physics engines take this into account (I dont think they do)

[Wingnut]

*nod*.  I believe the "ridge-runner" (center slider) is slightly behind the others... because of a tiny extra bounce when it lands.  This might indicate that ridge-runner restitution is treated slightly different (even though all sticks and blocks are set r = 0).  Not sure.

Update:  [link]  I was wrong.  I had my center stick slightly mis-positioned.  The ends of all three sticks... weren't flush.  In the 54 pg, I believe the back edge of the center block... was landing with its butt sticking out into the air... a few microns.  Now, the race is more even/fair. 

[Pryme8]

https://www.babylonjs-playground.com/#B5BDU#57

I extended the ground plane to see what the results where after they get off your "sticks" and for sure the one on the ridge behaves differently. 

[Wingnut]

https://www.babylonjs-playground.com/#B5BDU#58

Nah, it acts the same. 

The x position was imperfect... a tiny amount (in line 35), so the center slider was starting to tip sideways by the time it hit the ground.  I adjusted line 35 a bit, and turned the camera around.  Looks pretty close.  Wingnut imprecision.    I lean a little, or maybe my world is slightly tilted.  Or perhaps I need to take my browser into the shop for an alignment.

I am right handed, so my mouse and pad are located on right-side of my main keyboard.  Thus...  mesh needs to go -x a bit... -0.0395.  For lefties, with mouse and pad on left side... likely +0.0395.  heh. 

Ahhh... comedy... it's a dirty job but SOMEBODY has to do it.

[Pryme8]

https://www.babylonjs-playground.com/#B5BDU#60

this is more the behavior I expected
https://www.babylonjs-playground.com/#B5BDU#61
and if I increase the tilt it makes it drop to the other side on the ridge... interesting!

[Wingnut]

Hi gang!  Well, today I did some more TRYING... to constrain/restrain (with nativeParams min and max, or any other way I could think-up)... a Cannon hinge joint.  It seems these Cannon hinges don't accept min and max like Oimo hinges do.  Min/Max are tried in lines 94/95... and seem to do nothing.

I decided I wanted to "see" what joint1._physicsJoint.rotationalEquation2.maxAngle does... for Cannon hinges.  So, I animated/decremented that value... in line 198 render loop. 

It isn't the setting I was looking for, but it DID gently rotate the hinge axis, and I got to "see" it.  Yay.

Then my neighbor "art" came over, and he said "Hey, let's put a sparkly particle sprayer on the end of the pendulum so we can watch its trail."  I said "No... no art... this is purely a technical testing playground!"

Well, art still got his way... and turned my technical playground into an art-istic playground.  Friggin' whimsical neighbors... pfft. 

http://playground.babylonjs.com/#RLKVFF#42   (active keys X Y Z, and SHIFTED X Y Z - to impulse pendulum)

Classic problem with BJS.  Right in the middle of doing work, the playing takes over. 

[Wingnut]

Hey @Pryme8, you like cloth physics.  Have you seen this:  http://kripken.github.io/ammo.js/examples/webgl_demo_softbody_cloth/index.html

3JS and Ammo.js.  It's pretty smooth.  I think you should convert this to BJS, still using Ammo... and then we'll weigh/discuss whether to build an ammoPlugin class. 

Perhaps Oimo is already a renamed Ammo, eh?  All in all, that's pretty nice cloth.